On 25/07/12 07:25, Chris Frey wrote: > 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.
Both of those are good points. > 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. That's also a very good point. > 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? I did start by trying to do something similar but couldn't work out how to avoid the race between draining the incoming queue and registering the callback interest. If the registering of the callback is done first then it's possible for callbacks for new data to occur before the incoming queue is flushed. I think the alternative would be to support registering the callback before the socket is opened so that the packets can be routed correctly by the read thread while the thread opening the socket is still inside SocketZero::Open(). Unless I hear otherwise, I'll have a go at doing it this way and send an email to the list once I get some spare time. > 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. Sorry about taking so long to respond, I'm not waiting for anything from you, I'm just busy. I wanted to respond to your comments with suggested code fixes, but just as I think I've got time to do that something else turns up. Regards, Toby ------------------------------------------------------------------------------ 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
