On Mon, Jul 16, 2012 at 12:10:28PM +0100, Toby Gray wrote:
> I noticed a couple of issues with routing of data and sequence packets
> early on in channel setup if the device sends data to the PC quickly. I
> fixed these in
> https://github.com/tobygray/barry/commit/ebbdf4c9d5868a69d636119da354547918c70e1a
>
> and
> https://github.com/tobygray/barry/commit/6dff36f6c2cd1ef2c0006af2baebbf5ee0c0c291
I'm not overly keen on the TransferInterest() function. For one it
requires the non-scoped version of the scope_lock class, which I haven't
merged. And for another, it adds a new call point for callbacks.
Ideally, callbacks should occur from the same thread that calls DoRead,
whatever application thread is doing that main processing. I don't
think it is guaranteed that the worker thread will call TransferInterest().
In fact, I think it is likely that it won't.
Is there a way to avoid TransferInterest completely? The application is
in control of its read thread, and so is the raw channel code, if I'm
not mistaken. Is there no way to drain the incoming queue before we
transfer interest to a callback?
Thanks,
- Chris
P.S. I haven't heard much from you in response to my queries. If you're
just busy, that's ok, but if you're waiting for something from me,
please do let me know. :-) I've merged all I can so far.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
