The last several changes should resolve a series of fairly random segfaults
that have been observed at shutdown by Covalent's QA group [I was even
able to reproduce in 'console' mode.] Although I'd love another pair of eyes
on these latest changes, I'll include them in the .34 release so we don't
At 08:48 AM 4/2/2002, you wrote:
>stoddard02/04/02 06:48:54
>
> Modified:server/mpm/winnt mpm_winnt.c
> Log:
> Win32: tweak some messages
>
> Revision ChangesPath
> 1.255 +2 -2 httpd-2.0/server/mpm/winnt/mpm_winnt.c
The NOTICE level reversion and message tweaks wil
Now incorporated into APACHE_2_0_34
>stoddard02/04/01 10:55:46
>
> Modified:server/mpm/winnt mpm_winnt.c mpm_winnt.h
> Log:
> Win32: Move apr_bucket_alloc() to a more reasonable location to fix
> memory leak.
>
> Revision ChangesPath
> 1.253 +4 -6 httpd-2.0/server
[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 8:28 AM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
>
> At 08:41 AM 3/20/2002, you wrote:
>
> >yeah, but the new child process needs the same information as the old
> >
At 08:41 AM 3/20/2002, you wrote:
>yeah, but the new child process needs the same information as the old
>one did. Won't you need to pass the scoreboard to the new child, and
>isn't that done by the pre_mpm hook? I could very easily be wrong about
>which hook does that work, but the last time I
> >And, you
> >need to find some way to pass the scoreboard back to the child
process
> >because you are about to start a new one.
>
> What are you talking about, we killed Kenny :0/ This next generation
we
> have new offspring.
>
yeah, but the new child process needs the same information as t
Jeff Trawick <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
>
> > On 20 Mar 2002 [EMAIL PROTECTED] wrote:
> >
> > > wrowe 02/03/19 20:29:55
> > >
> > > Modified:server/mpm/winnt mpm_winnt.c
> > > Log:
> > > When restarting [always graceful on Win32], we don't repeat
[EMAIL PROTECTED] writes:
> On 20 Mar 2002 [EMAIL PROTECTED] wrote:
>
> > wrowe 02/03/19 20:29:55
> >
> > Modified:server/mpm/winnt mpm_winnt.c
> > Log:
> > When restarting [always graceful on Win32], we don't repeat pre_mpm
> > (Unix doesn't, we shouldn't either.) [Ryan
>wrowe 02/03/19 22:14:19
>
> Modified:server/mpm/winnt mpm_winnt.c
> Log:
> Fix a few listener-related lifetime issues [they are created in the
> open logs phase, only once.]
>
> -if (!set_listeners_noninheritable(pconf)) {
> +if (!set_listeners_noninheritable(s-
At 11:31 PM 3/19/2002, you wrote:
>On 20 Mar 2002 [EMAIL PROTECTED] wrote:
>
> > +if (!restart && ((parent_pid == my_pid) || one_process)) {
> >/* Set up the scoreboard. */
> >if (ap_run_pre_mpm(pconf, SB_SHARED) != OK) {
> >return 1;
>
>While I agree
On 20 Mar 2002 [EMAIL PROTECTED] wrote:
> wrowe 02/03/19 20:29:55
>
> Modified:server/mpm/winnt mpm_winnt.c
> Log:
> When restarting [always graceful on Win32], we don't repeat pre_mpm
> (Unix doesn't, we shouldn't either.) [Ryan Bloom]
>
> -if ((parent_pid == my
c mpm_winnt.h service.c
> At 12:07 PM 3/14/2002, you wrote:
> >Bill, does this resolve the Win32 showstoppers? Specifically...
> >
> > * Address popular PRs
> > * Win32 doesn't install as service correctly [9863, 9914, 9961]
> > * Don't be stupid and cd to a blank directory whe
At 12:07 PM 3/14/2002, you wrote:
>Bill, does this resolve the Win32 showstoppers? Specifically...
>
> * Address popular PRs
> * Win32 doesn't install as service correctly [9863, 9914, 9961]
> * Don't be stupid and cd to a blank directory when doing installs
> [PR 9993]
Bill, does this resolve the Win32 showstoppers? Specifically...
* Address popular PRs
* Win32 doesn't install as service correctly [9863, 9914, 9961]
* Don't be stupid and cd to a blank directory when doing installs
[PR 9993]
I'll not be too keen on Win32 holding up a
> > I disagree completely. The Windows MPM is fragile, because it is
almost
> > impossible to read. Bill has been cleaning it up so that multiple
> > people can easily modify the code and actually understand what is
> > happening.
> >
> > Knowing how much time Bill has spent reading through that
> > Can we fix the service restart problem before we go making other
> changes
> > to the MPM? I
> > see over the last few days there have been dozens of changes to the
> code,
> > none of which
> > are directed at fixing the service restart problem. All this monkeying
> > around with the
> > co
> Can we fix the service restart problem before we go making other
changes
> to the MPM? I
> see over the last few days there have been dozens of changes to the
code,
> none of which
> are directed at fixing the service restart problem. All this monkeying
> around with the
> code does is obscure
Can we fix the service restart problem before we go making other changes to the MPM? I
see over the last few days there have been dozens of changes to the code, none of which
are directed at fixing the service restart problem. All this monkeying around with the
code does is obscure finding what p
The important thing here is that the process yields to allow the child to initialize.
The
time of the sleep is really not important. The thing that needs to happen is deep in
the
OS, so I am not sure what we would mutex against. Yea, this does suck... it is a bug in
the OS AFAIK cause we should
On Saturday 10 November 2001 04:33 pm, Jeff Trawick wrote:
> Ryan Bloom <[EMAIL PROTECTED]> writes:
> > On Saturday 10 November 2001 01:07 pm, [EMAIL PROTECTED] wrote:
> > > rbb 01/11/10 13:07:13
> > >
> > > Modified:include http_connection.h
> > >server connection
Ryan Bloom <[EMAIL PROTECTED]> writes:
> On Saturday 10 November 2001 01:07 pm, [EMAIL PROTECTED] wrote:
> > rbb 01/11/10 13:07:13
> >
> > Modified:include http_connection.h
> >server connection.c
> >server/mpm/winnt mpm_winnt.c
> > Log:
> > Fi
On Saturday 10 November 2001 01:07 pm, [EMAIL PROTECTED] wrote:
> rbb 01/11/10 13:07:13
>
> Modified:include http_connection.h
>server connection.c
>server/mpm/winnt mpm_winnt.c
> Log:
> Fix the Windows MPM. Windows doesn't always use the linge
22 matches
Mail list logo
