On May 21, 2013, at 4:48 AM, Toby Gray <toby.g...@realvnc.com> wrote:
> On 20/05/13 23:43, Pete Batard wrote: >> On 2013.05.20 17:06, Nathan Hjelm wrote: >>> On May 20, 2013, at 09:51 AM, Toby Gray <toby.g...@realvnc.com> wrote: >>>> I've attached a handful of patches of changes needed to get WinCE >>>> building (I've not tried it on hardware yet). I suspect that people will >>>> have strong opinions on the first patch which creates poll_posix.c. >> Actually, even if the new source will be rather small, I think it'll >> make our implementation cleaner (especially as we already have a >> poll_posix.h anyway, that used to #define usbi_pipe), so with Nathan's >> reservations below, I'm +1 on this one. > > Excellent. That's good to know. > >>> If we want to abstract calls to pipe why not 1) make usbi_pipe take an >>> option as to whether the pipe should be blocking or non-blocking, >> Seconded. > > I've looked into this a bit more and I can't convince myself that the > use of the hotplug pipe isn't a bit broken. > > For the ctx->ctrl_pipe use of usbi_read() and usbi_write() only a single > byte is read or written. The value of this byte is ignored, it's > presence is just used to wake up any event handling. I think these > one-byte writes should really be non-blocking: if the buffer on the pipe > is full then the event handling will wake up eventually and so blocking > doesn't achieve anything. > > I think this means we do want to make ctrl_pipe non-blocking for writes. > > > For the ctx->hotplug_pipe use of usbi_read() and usbi_write() it reads > and writes sizeof(struct libusb_hotplug_message) every time. > > If the hotplug pipe is non-blocking for writes then only a partial > libusb_hotplug_message could be written onto the pipe, so a corrupt > message will be read. As reads are blocking the read would block anyway > until the next hotplug message was written to the pipe. > > If the hotplug pipe is blocking for writes then a thread could get stuck > in, for example, usbi_connect_device waiting for events to be processed. > Which also isn't ideal. This is exactly why I made the pipe non-blocking. The thread writing to the pipe might have other data to process (async io completion in the darwin case) so it shouldn't block if it can't write to the pipe. The reading side will possibly get a short read and throw the message away (with a error message). > I suppose this is all a bit academic as pipes have fairly large buffers, > needing 1000s of events to fill up the buffer (at least on Linux). I > don't know what other POSIX platforms are like though. Likewise on darwin/OSX. I have never seen a short read on the internal darwin backend pipe (which has the same non-blocking requirement) of the hotplug pipe). -Nathan ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
