apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: EGAIN, EINTR et.al.
Date Tue, 30 Oct 2001 13:42:38 GMT
Dirk-Willem van Gulik <dirkx@covalent.net> writes:

> On 29 Oct 2001, Jeff Trawick wrote:
> 
> > Dirk-Willem van Gulik <dirkx@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...

Mime
View raw message