Essentially, there’s only *two* changes I’d like to see in QSerialPort’s implementation. These changes may not be possible to implement on all platforms, of course. The `QSerialPort` API must be nonblocking, that’s the whole point of having it to start with. Doing blocking reads/writes is trivial using platform APIs - I don’t think QSerialPort should support any blocking operations.
Internally I use classes that behave that way and they work as well as anything in userspace can ever work, given that the code must be non-blocking. The writes should be executed right away if they won’t block. The semantics would be: 1. Check how many bytes can be written to the OS device buffers without blocking. 2a. If the buffer is empty, write as many bytes as possible from the data given to write, add remainder to the buffer. 2b. If the buffer is non-empty, append the data to the buffer, and drain as much of the buffer as possible. The reads should be executed right away if they wouldn’t block. The semantics would be: 1. Check how many bytes can be read from the OS device buffers without blocking. 2. Get everything from the OS queue and append to the buffer. 3. Drain as much of the buffer as requested in the argument to `read` and return to the user. On platforms where there is no non-blocking API for step #1, the read and write is forced to use the buffer only, as it currently does. Cheers, Kuba Ober On Apr 21, 2014, at 12:35 PM, Denis Shienkov <[email protected]> wrote: > Thiago, > > many thanks for your help. > > BR, > Denis > > 21.04.2014 20:12, Thiago Macieira пишет: >> Em seg 21 abr 2014, às 16:50:50, Denis Shienkov escreveu: >>> Hmmm.. >>> >>> Thiago, what do you mean by "writeable"? It is when device was opened in >>> the WriteOnly (ReadWrite) mode, or something else? >> When the underlying device can receive more bytes from the userspace. >> >> Sockets and pipes are buffered in the kernel. When you write to them, they >> don't get sent immediately (for sockets, specifically, there's Nagle's >> algorithm in place). They get buffered and sent later. >> >> That buffer is not unlimited in size. When you write too much, the OS will >> not >> accept more write() calls. That is, write() will return -EWOULDBLOCK. When >> that happens, you need the QSocketNotifier for Write to tell you when it's >> acceptable to write again. >> >> QAbstractSocket and QProcess always put the data in their own buffer during >> writeData(). Then they enable the QSocketNotifier for Write, if it wasn't >> enabled. >> >> When that notifier fires, in the event loop, the actual writing to the OS >> happens. >> >>> If I correctly understand, then I assume that the device always is >>> "writeable": i.e. opened in WriteOnly (ReadWrite) and the internal buffer >>> of writing is not empty. >> You assume wrong. Therefore, the rest of the email does not make sense. >> > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
