gls at gknw
Apr 10, 2012, 1:11 PM
Post #6 of 8
I agree 2.3.7 needs to be released for the stated reasons, I was +1 to
that back a few weeks ago.
On 4/10/2012 9:11 AM, Jeff Trawick wrote:
> On Tue, Apr 10, 2012 at 12:35 AM, William A. Rowe Jr.
> <wrowe [at] rowe-clan> wrote:
>> On 4/9/2012 11:30 PM, William A. Rowe Jr. wrote:
>>> The patch does have value to a limited number of applications. I even went
>>> as far as to put caviats in the docs, and a see-docs note to the directive
>>> cmd commentary. I hope it dissuades the casual user from throwing it on there
>>> unless they know it won't corrupt their app and know it solves their bug.
>>> Please reconsider your veto. I agree that it -should not- occur in any
>>> real world scenario. But there are unreal scenarios of server configs
>>> and third party modules which spend minutes, not seconds, tearing down on
>>> shutdown. Those are the bugs. But users just want some help and I think
>>> this patch is some help in rare cases. Disabled by default and won't be
>>> used by much of anyone, we hope. I'll revert (yet again) if you really
>>> want to make a case that we should never support this, even as a workaround.
As far as my specific veto, I wouldn't call it a veto but more a concern
as it's untested code vs. 50309 which is well tested, I'm trusting your
knowledge here. Bill, your caveats in the docs about cleanup, being
experimental and off by default is good enough for me. I should be able
to build and do a little testing within the next 48 hours.
I'll have to look over the 50120 &51520 statement of mine hopefully
within same time frame. I may have mixed up the number quit easily!
>> Gregg, and Jeff and company, if this is reviewed and everyone is happy with
>> an end result, I'd like to ensure 2.4.2 compatibility and get tagging.
> My gut feel is that the feature will help in some real world
> circumstances, but I need to stare at Windows-specific code for a
> while to really understand the problem (where third-party modules can
> intervene, where a timeout comes into play, etc.). At first glance it
> seems to simply be the case when apr_proc_kill(SIGKILL) doesn't work
> for whatever reason (third-party code, but not the usual code we worry
>> We seem well overdue for a release.
>> There is a group of issues with spaces in command lines, spaces in file names
>> that need to be resolved for the typical windows scenario (and obviously also
>> unix, just more unusual there). I think we are best off calling 2.3.7 about
>> baked right now, tagging, reviewing and releasing, and calling 2.3.next the
>> flavor which fixes these command/file string argument quirks.