On Thu, Oct 14, 2010 at 11:05:13AM +0100, Toby Gray wrote: > An alternative might be to use a timeout when performing the receives in > Socket::Close. However my thinking was that as there is no chance of > receiving any data, it seems a bit pointless to make the user wait. > Although writing this now has made me wonder if we should just add a > timeout to the receives in Socket::Close anyway. > > If a SocketRoutingQueue isn't being used then this doesn't appear to be > an issue as then the default USB read timeout specified by m_timeout is > used in Device::BulkRead, so the close will timeout eventually.
You hit the nail on the head here... it's a design bug, or a conflict between two designs. The default timeout for USB is 30 seconds (or whatever the #define is during the compile), while the default timeout for the DataQueue, and therefore the router, is forever. Oops. :-) I've pushed a change that makes the router behave like usbwrap, in that it takes a default timeout in the constructor, and then the reads use -1 to use that default. Thanks for spotting that. - Chris ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
