Regarding EAGAIN error in read()

[Madhu]

Hi,

I need to trap EAGAIN error while using read().

I read in some website that read() has to wait till write() is
completed for EAGAIN to occur. But read() doesnt seem to wait, it reads
whatever it can and stores it in the buffer and sets the rest of the
buffer to NULL.

Thanks,
Madhukar

 

[Walter Roberson]

I need to trap EAGAIN error while using read().

Try asking in comp.unix.programmer . The C language itself does not
have read() or EAGAIN: they are extensions beyond the standard.

I read in some website that read() has to wait till write() is
completed for EAGAIN to occur.

Don't trust that website.

But read() doesnt seem to wait, it reads
whatever it can and stores it in the buffer and sets the rest of the
buffer to NULL.

Don't trust that test.

 

[Papastefanos Serafeim]

I've never heard of the behaviour you mention.
The standard behavior for read is to read anything
available in the stream and return.

If there is no data available, then if read is reading
from a blocking descriptor it will block. If read is
reading from a non blocking descriptor then it will
return with an EAGAIN or EWOULDBLOCK
error.

Also, read and write are not in standard C, so
maybe in another newsgroup you'll get a better
answer than mine.

Papastefanos Serafeim

 

[Keith Thompson]

I've never heard of the behaviour you mention.
The standard behavior for read is to read anything
available in the stream and return.

If there is no data available, then if read is reading
from a blocking descriptor it will block. If read is
reading from a non blocking descriptor then it will
return with an EAGAIN or EWOULDBLOCK
error.

Also, read and write are not in standard C, so
maybe in another newsgroup you'll get a better
answer than mine.

Please don't top-post. See <http://www.caliburn.nl/topposting.html>.

Please don't offer detailed answers to off-topic questions. The
experts on this stuff hang out in comp.unix.programmer. If you make a
mistake in your answer here (we all make mistakes), we're not going to
be able to correct it If we do, it will likely lead to a lengthy
off-topic discussion that should have been in comp.unix.programmer in
the first place.