-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronous Support #13
Comments
Considered, yes, but I can say it isn't on a roadmap nor does it have an expected date. It would be unlikely for us to add a queue structure to the library itself or implement a thread model since these things are usually very implementation specific and are better off handled by the application code than a library like this one. If you aren't in .NET 4.5 then I'd suggest managing an LRS thread(pool) yourself to deal with the blocking. Having said that, my approach would likely use .NET 4.5's async/await capability through the HttpWebRequest. I've not looked into whether we could issue different dll's for the two versions or how that might look. I'm not too opposed to forcing people on to a newer version than 3.5, but they'd have to be getting something significant (which async might be enough to warrant). To that end, pull requests are accepted if well conceived and hopefully with unit tests. The RemoteLRS class has a |
I should have also included that we consider bounty based work on any of our OSS libs, if you want a defined approach and timeline. |
Thanks Brian, |
I'm working on integrating this TinCan library into some software and am finding that it freezes briefly whenever I try writing some data to the LRS. Has there been any thought towards making this asynchronous? Ideally it could internally manage an ongoing queue of requests rather than blocking for each one.
The text was updated successfully, but these errors were encountered: