RE: VMIN/VTIME and read expectations

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

In effect, you're set up to be using non-blocking I/O.  In that case,
read() is supposed to set errno to EAGAIN to indicate that it failed
because nothing was available.  So the way to tell would be to check
errno.  (I'm not sure how you'd tell from a C streams level, but since
you've gone to read, it doesn't matter.)
 
Craig


-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Joel Sherrill
Sent: Thursday, December 17, 2009 6:28 PM
To: Eric Norum
Cc: newlib@sources.redhat.com
Subject: Re: VMIN/VTIME and read expectations

On 12/17/2009 04:30 PM, Eric Norum wrote:
> When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file'
doesn't really exist.
>    

I was kind of guessing that.  Unfortunately  this is in the RTEMS login 
code.
I can make it work OK for serial ports but when attached to a socket, I
have no idea how to detect when the socket is dropped.

I switched to calling read() and as documented, it always returns 0
when there is no data.  When the connection is dropped, it returns 0
VERY quickly.  Do you think this part is a bug in the read on a socket?

If this turns into an RTEMS specific issue, we need to switch lists.
But I would really like to know what is correct. :)

--joel
> On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
>
>    
>> Hi,
>>
>> I have been looking into a program on RTEMS that
>> uses VMIN=0, VTIME=255. The program calls
>> fgetc() which calls read().
>>
>> fp->_flags == 0x2806 before the fgetc() call.
>> read() times out and returns 0.
>> fgetc() returns -1 and fp->_flags == 0x2826
>>
>>
>> The 0x0020 being set is _SEOF.
>>
>> My questions are:
>>
>> + Is this correct behaviour?
>>
>> + How does the application programmer distinguish
>> between a real EOF and an unsatisfied read?  Even the
>> Fedora read(2) man page says:
>>
>>        On success, the number of bytes read is returned (zero
indicates end of
>>        file), and the file position is advanced by this number.
>>
>> So even if I dropped down to read(2), I still don't know
>> how to distinguish EOF from a read timeout.
>>
>> Thanks.
>>
>> -- 
>> Joel Sherrill, Ph.D.             Director of Research&   Development
>> joel.sherrill@OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>    Support Available             (256) 722-9985
>>
>>
>>      
>    


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