On Tuesday 15 December 2015 23:08:39 you wrote: > 1. When the registered callback fires with the EV_WRITE flag set on the > third argument, does that mean the port associated with the file descriptor > is ready to be written to
Correct. However, this "write ready event" is not necessarily triggered directly by the level on the CTS line. There are buffers in between, on OS level and even on your UART in hardware. I don't know how it's implemented on Linux but I can imagine a "write ready" event could be triggered if some buffer has space to take up new data, even though there's still data in the send queue. Currently, there's no good way to check on the send status of your serial device. Linux has the TIOCSERGETLSR ioctl, which will tell you the status of your hardware send queue, but this is not implemented for all serial hardwares and it certainly is not portable. Consequently, a write ready event is no guarantee, that you will be able to write all of your data. You need to check the return value of write() for how much has been added to the socket's send buffer. > 2. And when the callback fires with a EV_READ flag set - it would be > synonymous with a call back registered from a sigaction structure with the > O_ASYNC flag set on the file descriptor? As Marc said, it tells your program that a call to read() should not block on that file descriptor. Signal handlers can be called at any point in program flow of your main process, so there are similar issues as you do have with threads. And that is truly the beauty of an event library like libev: You can do away with both those crutches to implement non-blocking I/O, without worrying about OS specific backends. -- Best regards, Thilo Schulz _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
