ISO Example for reading/writing uart/rs-232

Marc Lehmann schmorp at
Wed Dec 16 02:04:46 CET 2015

On Tue, Dec 15, 2015 at 11:08:39PM +0000, Chris Galas <ChrisG at>

> 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 (like the CTS, clear-to-send bit
> being read)?

EV_WRITE means that write() should be able to accept some bytes, not more,
not less.

Whether CTS has any influence on that depends on the actual port
configuration and probably also on how the OS implemenets it, so I don't
think you can rely on portable rules here.

> 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?

No, signal handling and libev callbacks are very different - for one
thing, SIGIO (for example) is unreliable and might or might not get
generated, while libev callbacks are reliable and will keep "firing" when
read() would not block.

> Or am I over thinking this?

Maybe, in the sense that libev does any serial port handling for you - it
only is concerned about whether read or write (or similar calls) will block
or not.

How your OS maps serial pin levels to events is completely outside the
scope of libev. Unless you really *need* to do soemtrhing etxremely weird,
such as using CTS for communication instead of letting the kernel driver
handle I/O for you, you don't have to concern yourself with that - just
configure your serial port according to the OS documentation, and libev
will then be able to tell you when to read and write data.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list