Hold the tag for the resolution? Jeff, do you want to patch?
Bill
----- Original Message -----
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 19, 2001 3:55 PM
Subject: Re: [PATCH] Fix POD reading...
> 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
>
>
