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. 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. Regards, Toby ------------------------------------------------------------------------------ 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
