httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] Fix POD reading...
Date Thu, 19 Jul 2001 20:55:38 GMT
On Thu, Jul 19, 2001 at 04:15:48PM -0400, Jeff Trawick wrote:
> On what platform do you see rv APR_SUCCESS/len 0 when there is nothing
> to read from the pipe?
> 
> Ooh, Solaris does this!

Yup.  I'm not insane.  The POD doesn't work on Solaris without this
patch.  =)

> Of course, it isn't the prettiest thing to implement.  Here we're
> using a socket call (apr_recv) on a pipe :)  Only the file code knows
> it is a pipe.  You have to know it is a pipe to decide that rc==0 on
> such a platform means EAGAIN.

How do we test for this in autoconf (unless we specify something in
hints)?

In the threaded MPM, since we're specifying a timeout and that sets 
O_NDELAY (we're setting O_NONBLOCK as well), we're hitting the 
following clause in the Solaris read(2) manpage:

     When attempting to read from an empty pipe (or FIFO):

        o  If no process has the pipe open  for  writing,  read()
           returns 0 to indicate end-of-file.

        o  If some process has the  pipe  open  for  writing  and
           O_NDELAY is set, read() returns 0.

        o  If some process has the  pipe  open  for  writing  and
           O_NONBLOCK is set, read() returns -1 and sets errno to
           EAGAIN.

Hmm.  And, this is tricky because we're referencing the POD as a socket
not as a file in the threaded MPM.

And, if we switch the threaded MPM to use the mpm_common code (treat 
it as a file), we're not notified when we have an incoming POD signal 
(like we are when we treat it as a socket).  Ugh.  Maybe we could do 
both?  Do the poll as a socket and read the POD as a file?  -- justin


Mime
View raw message