From: Martin Wheatley (Martin.Wheatley@jet.uk)
Date: Mon Nov 06 2006 - 08:33:49 EST
Dear Sun Managers and any SMI staff who read this list
Please,
Is there anyone out there who can provided a detailed explanation to the following issue.
I realise that this is a "C Language question" more that a Sun Management question but I'm
hoping that someone in SMI will pick up the issue and discuss it with me.
Functions like fopen/fread/fwrite/fprintf/fclose use the open(2), read(2), write(2), and close(2) system calls to
connect FILE *s to FDs and to transfer data to/from internal buffers the the underlying FDs, and to close FILE *s.
The open()/read()/write()/close() system calls may 'fail' with errno == EINTR however it is programatically
impossible for the user of fprintf()/fread()/fwrite()/... to retry the function call because there is no way to work out
what data was transferred to the underlying FD and what was not.
The fact that EINTR failures are not retried automatically means that the standard I/O functions should be considered
as NOT reliable and should NOT be used in applications where the reads/writes/opens/closes may be interrupted,
nor can they be used by libraries (whether they be private libraries or public ones - such as libc!) since
the library developer MUST assume that they library will be used by an application that my result in the EINTRs
being generated.
My question, therefore, is...
"Why do the standard I/O functions not automatically retry open()/read()/write() calls that fail with EINTR"?
-- +------------------------------------------------------------------+ | Martin Wheatley | Voice : +44-(0)1235 464784 | | CODAS | Mobile: +44-(0)468 894818 | | UKAEA, Culham Division | FAX : +44-(0)1235 464404 | | Culham Science Centre | | | Abingdon, Oxfordshire | | | OX14 3DB | E-mail: Martin.Wheatley@JET.UK | | United Kingdom | or: Martin.Wheatley@UKAEA.Org.UK | +------------------------------------------------------------------+ _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:41:08 EDT