alarm / setitimer question and serial record communication

[Joel Sherrill <joel@OARcorp.com>]

Peter Dufault wrote:
> I have some serial port code that I want to run on both RTEMS and a 
> POSIX system without change, and preferably, because I want to, without 
> any ifdefs.
> 
> The POSIX termios VMIN / VTIME interface is bizarre in that I can't 
> (though I've looked at it many times) put together a bullet proof 
> interface that handles the remote end disappearing and the local end 
> then recovering while I'm only the termios timeout interface.
> 
> If you set an initial timeout, then that timeout corresponds only to the 
> first received byte, and the read returns after that one byte.  If you 
> set an interbyte timeout, then the first byte timeout has to be infinite 
> since the interbyte timeout won't come into effect until the first byte 
> is received.
> 
> To work around this I usually set a timeout on the first received byte 
> to know that the remote end is alive, I then check the received byte for 
> consistency, and then I set the interbyte timeout for the balance of the 
> record for the number of bytes I expect.  Then, in case the remote end 
> dies after starting to talk and before finishing talking, I wrap it the 
> read call with an alarm that will interrupt the read in the rare case 
> that the remote end dies.
> 
> This code doesn't work on RTEMS.  It seems to work unless the remote 
> device disappears after the first byte is received, but that means it 
> doesn't work. "setitimer" doesn't exist on RTEMS, and "alarm" doesn't 
> interrupt the thread doing a read even if I brute-force enable SIGALRM.
> 
> Am I missing a way to keep this part of my library portable (without 
> ifdefs)?  There is one way I don't like, which is to revert to doing 
> single byte I/O using the POSIX initial timeout (the timeout that 
> returns as soon as the timeout elapses or a single byte is received).  
> That approach is OK on an embedded system but isn't OK for a portable 
> POSIX library that doesn't like ifdefs.

My answer in cases like this is always to fix the RTEMS implementation
to match the expected standard behavior.   Provide test case and
documentation updates.

It is easier to fix a few lines of code in RTEMS than to hack around
in user space.  This is how RTEMS has grown over the years.  Each person
adds a little and enhances a little.  This lays the groundwork for a new
set of applications.  SOme of those apps will in turn need a bit more
functionality which trips the next threshhold.


> Is there is a more modern (than alarm for example) POSIX approach that 
> will work on both RTEMS and modern POSIX systems?
> 
> Peter
> 
> 
> Peter Dufault
> HD Associates, Inc.
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985