Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31063 invoked by uid 500); 30 Oct 2001 00:57:36 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31052 invoked from network); 30 Oct 2001 00:57:36 -0000 Date: Mon, 29 Oct 2001 16:52:59 -0800 (PST) From: Dirk-Willem van Gulik X-X-Sender: dirkx@titatovenaar.sfo.covalent.net To: Jeff Trawick cc: dev@apr.apache.org Subject: Re: EGAIN, EINTR et.al. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 29 Oct 2001, Jeff Trawick wrote: > Dirk-Willem van Gulik 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