EGAIN, EINTR et.al.

[Dirk-Willem van Gulik <di...@covalent.net>]

Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().

But on some platforms you can get things like EWOULDBLOCK and EINTR too.

In APR is there a convenient macro to figure out if the exit code is a
'hard' error (say EINVAL, EBADF, ENOTSUPP) or one to figure out if it is
a retryable type error ?

Dw

Re: EGAIN, EINTR et.al.

[Jeff Trawick <tr...@attglobal.net>]

Dirk-Willem van Gulik <di...@covalent.net> writes:

> On 29 Oct 2001, Jeff Trawick wrote:
> 
> > Dirk-Willem van Gulik <di...@covalent.net> writes:
> >
> > > Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().
> >
> > since a couple of unices return EACCESS for the retriable
> > somebody-else-has-the-lock situation that most unices return EAGAIN
> > for
> ...
> > APR_STATUS_IS_EAGAIN(status) will tell you if somebody else has the lock
> 
> Right now with EINTR, EAGAIN and EWOULDBLOCK and the EACCESS with Apr
> does in house I can cover linux,hpux,aix,solaris and *bsd - even under
> funky (benchmark) circumstances (when the EINTR is the issue).

Just to restate the obvious yet again...  An APR app shouldn't see
EINTR from a lock operation (or most any operation).  Also,
APR_STATUS_IS_EAGAIN() checks for EWOULDBLOCK too if appropriate for
the system (i.e., if EWOULDBLOCK is defined and EWOULDBLOCK !=
EAGAIN).

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: EGAIN, EINTR et.al.

[Dirk-Willem van Gulik <di...@covalent.net>]

On 29 Oct 2001, Jeff Trawick wrote:

> Dirk-Willem van Gulik <di...@covalent.net> writes:
>
> > Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().
>
> since a couple of unices return EACCESS for the retriable
> somebody-else-has-the-lock situation that most unices return EAGAIN
> for
...
> APR_STATUS_IS_EAGAIN(status) will tell you if somebody else has the lock

Right now with EINTR, EAGAIN and EWOULDBLOCK and the EACCESS with Apr
does in house I can cover linux,hpux,aix,solaris and *bsd - even under
funky (benchmark) circumstances (when the EINTR is the issue).

But yes - I see the problem - each call type; i.e. lock, read/write,
connect et.al. would each have to have it's own IS_RETRYABLE().

Dw

Re: EGAIN, EINTR et.al.

[Jeff Trawick <tr...@attglobal.net>]

Dirk-Willem van Gulik <di...@covalent.net> writes:

> Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().

since a couple of unices return EACCESS for the retriable
somebody-else-has-the-lock situation that most unices return EAGAIN
for

&&

(bad reason coming on) testflock.c assumes
APR_STATUS_IS_EAGAIN(status) will tell you if somebody else has the lock

> But on some platforms you can get things like EWOULDBLOCK and EINTR too.
> 
> In APR is there a convenient macro to figure out if the exit code is a
> 'hard' error (say EINVAL, EBADF, ENOTSUPP) or one to figure out if it is
> a retryable type error ?

certainly more stuff is needed here, but would probably be more
specific than is-hard-error or is-retriable-error or even
is-hard-file-lock-error or is-retriable-file-lock-error
(does-some-loser-have-the-lock())

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Re: EGAIN, EINTR et.al.

[David Reid <dr...@jetnet.co.uk>]

> Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().
>
> But on some platforms you can get things like EWOULDBLOCK and EINTR too.
>
> In APR is there a convenient macro to figure out if the exit code is a
> 'hard' error (say EINVAL, EBADF, ENOTSUPP) or one to figure out if it is
> a retryable type error ?

Don't think we have one, but it may not be a bad idea as we could wrap up
the platform differences nicely and make our code more readable...

Only thing is would we need a lot of basically identical macro's just for
different calls (sockets, files, flocks and so on).  Worth a look.

david