On Wed, Apr 25, 2001 at 02:06:24PM -0400, Rodent of Unusual Size wrote:
> [EMAIL PROTECTED] wrote:
> >
> > I now have a patch that compiles cleanly, and should completely
> > remove the pipe_of_death. The basic idea is that everything is
> > done through signals, using the SIGWAIT logic. As for waking
> > threads up from apr_poll, that is done by connecting to the socket
> > from the server itself, and then immediately closing the socket.
>
> Ugh. Ick. -1. If the system's stack is hosed, or the network
> is being shut down (think OS/390), this can cause problems. Or
> think of a protocol module that is not even talking to the network,
> but is doing some other kind of job. Never send your control
> functions over the data channel; they need to be out of band from
> the data.
>
> We got away from the 1.3 signal module for well-known reasons.
> The pipe_of_death is cross-platform safe and provides the necessary
> granularity, but interferes with SINGLE_LISTEN_UNSERIALIZED_ACCEPT.
> Any replacement for pipe_of_death must not introduce any regressions;
> using the data channel will do so for the reasons stated above.
> Some other mechanism may have the advantages of pipe_of_death
> without its drawbacks, but this is not it.
Ummm, speaking as someone who has very little confidence that the
pipe of death works reliably at all, the only requirement is that the
replacement works better than what we have now in CVS. The claim
that the pipe of death is somehow better than 1.3 signals is just wrong.
It may be more portable, but that is why we have #ifdefs.
....Roy
