I'm working on a small xml batch file loader
and I have a question:

If the open () function failes and errno is set
to EINTR should I try again until is passes or
failes for some other reason?

Is this a "good" way to handle EINTR?

Thanks

[ Post a follow-up to this message ]

Yes, but it won't happen if you are opening a file because, in that
case, open() is uninterruptible. You wouldn't "normally" expect a signal
to arrive during an open() in any case.

isillight wrote:
> I'm working on a small xml batch file loader
> and I have a question:
>
> If the open () function failes and errno is set
> to EINTR should I try again until is passes or
> failes for some other reason?
>
> Is this a "good" way to handle EINTR?
>
> Thanks

[ Post a follow-up to this message ]

Robert Harris <robertdotfdotharris@blueyonder.co.uk> wrote:
> isillight wrote: 
>
> Yes, but it won't happen if you are opening a file because, in that
> case, open() is uninterruptible. You wouldn't "normally" expect a signal
> to arrive during an open() in any case.

Why shouldn't a signal arrive when you call open(), being it for a
normal file or a device file, so why do you think it's uninterrupt-
ible? Since signals happen asynchronously I can't see what should
protect an open() of just a normal file, especially without knowing
where the file resides.

In place of the OP I would simply again call open() until it succeeds
(or returns with some other error), of course unless receipt of the
signal has some special meaning that would make continuing with
opening the file useless.
Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

Ah! Well, traditionally system calls are either "slow" or "fast" -
"slow" ones are those that can block for ever. (I am quoting from
"Advanced programming in the UNIX Environment" by W Richard Stevens).
"slow" calls are interruptible, "fast" ones are not.

Signals can only be accepted by processes while they are in functions
that are "interruptible".

And even otherwise interruptible calls may restart after a signal is
accepted rather than return -1 with EINTR set, depending on the
disposition of the SA_RESTART flag for that signal.

Robert

Jens.Toerring@physik.fu-berlin.de wrote:
> Robert Harris <robertdotfdotharris@blueyonder.co.uk> wrote:
> 
>
>
> Why shouldn't a signal arrive when you call open(), being it for a
> normal file or a device file, so why do you think it's uninterrupt-
> ible? Since signals happen asynchronously I can't see what should
> protect an open() of just a normal file, especially without knowing
> where the file resides.
>
> In place of the OP I would simply again call open() until it succeeds
> (or returns with some other error), of course unless receipt of the
> signal has some special meaning that would make continuing with
> opening the file useless.
>                                   Regards, Jens

[ Post a follow-up to this message ]

Robert Harris <robertdotfdotharris@blueyonder.co.uk> wrote:
> Ah! Well, traditionally system calls are either "slow" or "fast" -
> "slow" ones are those that can block for ever. (I am quoting from
> "Advanced programming in the UNIX Environment" by W Richard Stevens).
> "slow" calls are interruptible, "fast" ones are not.

> Signals can only be accepted by processes while they are in functions
> that are "interruptible".

But does this make every open() of a "normal" file uninterruptible?
I am wondering about cases where the file to open e.g. resides on
a NFS-mounted disk. Wouldn't that qualify as a "slow" system call
- if no proper timeouts are set for the NFS connection it could
block forever, coudn't it?

> And even otherwise interruptible calls may restart after a signal is
> accepted rather than return -1 with EINTR set, depending on the
> disposition of the SA_RESTART flag for that signal.

Yes, of course, as long as the OP has an handler installed for the
particular signal s/he's getting.
Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

<Jens.Toerring@physik.fu-berlin.de> wrote in message
news:c10mph$1ch16f$1@uni-berlin.de...
> Robert Harris <robertdotfdotharris@blueyonder.co.uk> wrote: 
 

> But does this make every open() of a "normal" file uninterruptible?

No, it does not. And it would be a design flaw to assume that opening a
file will be an uninterruptible operation even though it is quite likely to
be.

> I am wondering about cases where the file to open e.g. resides on
> a NFS-mounted disk. Wouldn't that qualify as a "slow" system call
> - if no proper timeouts are set for the NFS connection it could
> block forever, coudn't it?


Sure. Opening a serial port could certainly be a slow system call too.

DS

[ Post a follow-up to this message ]

David Schwartz wrote:

> <Jens.Toerring@physik.fu-berlin.de> wrote in message=20
> news:c10mph$1ch16f$1@uni-berlin.de...
>=20 
>=20
>=20 
>=20
>=20 
>=20
>=20
>     No, it does not. And it would be a design flaw to assume that openi=
ng a=20
> file will be an uninterruptible operation even though it is quite likel=
y to=20
> be.

As a matter of fact it is likely to be interrupted.

Take as an example the open a fully qualified path name.

"/" must be read to find the name of the next directory down
get it's node number.

The process is repeated for every directory in the
fully qualified pathname.  This may involve several
physical disk reads which are on the order of
milliseconds.  Thus, open is a "blocking" system
call which may get interrupted while the disk is
being read.


>=20
>=20 
>=20
>=20
>=20
>     Sure. Opening a serial port could certainly be a slow system call t=
oo.
>=20
>     DS
>=20
>=20
>=20
>=20

--=20
=D1
"It is impossible to make anything foolproof because fools are so=20
ingenious" - A. Bloch

[ Post a follow-up to this message ]

On Wed, 18 Feb 2004 14:24:36 -0800,
David Schwartz <davids@webmaster.com> wrote:


><Jens.Toerring@physik.fu-berlin.de> wrote in message
>news:c10mph$1ch16f$1@uni-berlin.de...

> 
>
>
>    Sure. Opening a serial port could certainly be a slow system call too.
>


Especialy when the open() call is suspended until DCD is detected on the
modem port.  Traditional NFS calls are uninterruptible with the effect
that if the NFS server is down the process trying to access it isn't
killable until the NFS server is back online.  Usualy there is a mount
option to change this behaviour with the usual warning to only do this
if the NFS file system is mounted read-only.


Villy

[ Post a follow-up to this message ]

Robert Harris <robertdotfdotharris@blueyonder.co.uk> writes:
> isillight wrote:
 
>
> Yes, but it won't happen if you are opening a file because, in that
> case, open() is uninterruptible. You wouldn't "normally" expect a
> signal to arrive during an open() in any case.

I've had EINTR from open() on a regular file, even when when the
relevant signal handler was set with SA_RESTART.  I think you're being
optimistic.

--
http://www.greenend.org.uk/rjk/

[ Post a follow-up to this message ]