Short: We need to call ap_close_listeners() earlier or more aggressively.
Question: Where/How?
Looking at the Event MPM in both trunk and 2.2.x, the listener_thread is
where we call ap_close_listeners(). This does not seem to be working
quickly enough, per PR 43081:
http://issues.apache.org/bugz
William A. Rowe, Jr. wrote:
>
> Jim Jagielski wrote:
> >
> > Of course, releases can't be vetoed, but doing further research
> > indicates that Bill looks to be spot on with this issue...
>
> The point is, this was released. Iteratively. I'm just not in a mood
> to keep +1'ing releases while t
On Mon, Aug 20, 2007 at 03:36:59PM -0500, William Rowe wrote:
> The crux of the problem is that we create processes without a full host
> of three fd's. Then we inflict them against sh. Linux/bash doesn't seem
> to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/sh are
> not going
Jim Jagielski wrote:
>
> Of course, releases can't be vetoed, but doing further research
> indicates that Bill looks to be spot on with this issue...
The point is, this was released. Iteratively. I'm just not in a mood
to keep +1'ing releases while the code remains in this broken state.
It bec
On Aug 20, 2007, at 4:36 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression rela
Jim Jagielski wrote:
> Status Update:
> There are issues in the current shipping version of
> APR 0.9 that must be resolved before we can reroll 2.0.x.
> Furthermore, there are issues in APR 1.2 that should be
> fixed (although not regression related) before we redo
> 2.2.x... Once APR is tagged an
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression related) before we redo
2.2.x... Once APR is tagged and rolled, we will use
that to T&
On 8/20/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Just a quick update; I have windows running again after creating a NUL
> (/dev/null) association for the parent processes' stdout handle. It solves
> a regression introduced in r483967 on Windows.
D00d!!
Just a quick update; I have windows running again after creating a NUL
(/dev/null) association for the parent processes' stdout handle. It solves
a regression introduced in r483967 on Windows.
I'm somewhat puzzled, on traditional unix, NO_PIPE values for stdin/out/err
would pass no fd at all, AIU
