On Tue, Apr 28, 2015 at 6:50 AM, Martin Ling <martin-sig...@earth.li> wrote: > Hi Cody, > > I take your points. Rather than discuss the rest further I think it's > most useful to focus on the following: > >> Perhaps on windows it would. On linux "read-at-least-x" can be done >> almost entirely in the kernel (via setting VMIN) >> My point is that if there was a higher level API the library could >> choose to use os-specific impls if avaliable (and if they made sense), >> otherwise fall back to a generic method that uses the existing API. > > As I've said already, we *can't* set VMIN and use the kernel's support > for this. To do that we would need to open the port without O_NONBLOCK, > which would prevent sp_nonblocking_read() and sp_nonblocking_write) from > working unless the port was reopened first.
You're right, it becomes more tricky, and isn't a clear win. I hadn't thought about needing to support both. Generally, fcntl() could be used to set/clear the O_NONBLOCK flag without re-opening (assuming there isn't any race danger here), but that's extra work on every read. > It was a specific design goal of the library to be able to support both > blocking and non-blocking operations on the same port without reopening > it. This was because it's a specific pain point when writing drivers for > serial devices: either you open the port non-blocking and have to set > up blocking when you want it, or you open it blocking and have to bodge > things with select() and single-byte requests, whenever you want to > ensure you don't block. And all this code maps maps badly to Windows, > which uses an async request model rather than POSIX-style nonblocking I/O. > > Providing separate blocking and nonblocking operations, so that you can > decide which you want at every call site, has massively simplified this > stuff for us and fixed dozens of subtle bugs in the process. > > I say this to explain why the obvious answer: specifying what behaviour > you want at sp_open() time - is not an acceptable option for me. > > So - I could add a function which has the semantics you want, but it > would do exactly the same thing as calling sp_wait() followed by > sp_nonblocking_read(). It would not actually set VMIN=1. Do you see that > as worthwhile? I think it's a toss up. It's something I'd commonly use, so I'd probably end up with a local impl (which would be similar to an internal one) anyhow. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
