Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> > 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)?
pipe()
set read handle non-blocking
call read() on read handle of pipe
if rc=0, then this is Solaris^H^H^H^H^H^H^Ha platform which acts like
Solaris in this respect
> 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
wow... (setting both)
> 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.
>
wow again... maybe we should do O_NONBLOCK instead of O_NDELAY?
> 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
I was thinking that we'd want to do the poll as a socket and read the
POD as a file.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
