You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/05/01 14:53:10 UTC
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
jerenkrantz@apache.org writes:
> jerenkrantz 02/05/01 00:15:40
>
> Modified: . CHANGES
> server/mpm/worker worker.c
> Log:
> Close sockets on worker MPM when doing a graceless restart. This should
> resolve some segfaults see when doing such restarts.
(My apologies for not keeping up with the discussions over the past
days.)
I don't see (yet) which segfault this would fix. Maybe I was hoping
for a fix to the wrong problem...
If this was to be combined with a change to do a thread-join on the
workers even for graceless termination, then I can see how the
segfault caused by cleaning up a pool that the worker threads depend
on would be avoided. (But of course a thread-join on a worker could
hang for a while, depending on what a 3rd-party module is doing.)
This change alone doesn't do much for the race between the main thread
cleaning up pchild and the worker threads getting dispatched and
realizing that they can exit and finally finishing their use of data
in subpools of pchild and doing the pthread_exit().
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Roll of 2.0.36, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
Posted by Jeff Trawick <tr...@attglobal.net>.
"Sander Striker" <st...@apache.org> writes:
> Hi,
>
> I was going to roll 2.0.36, but I want to wait for this last
> worker change. Unfortunately I don't have the time to pursue
> the issue now, so if someone does, please feel free to take
> care of this annoying beast.
I'll start working on it now. It shouldn't be hard to add a join for
graceless termination.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Roll of 2.0.36, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
Posted by Eli Marmor <ma...@netmask.it>.
Sander Striker wrote:
> I was going to roll 2.0.36, but I want to wait for this last
> worker change. Unfortunately I don't have the time to pursue
> the issue now, so if someone does, please feel free to take
> care of this annoying beast.
BTW: Is there any problem with the CVS version of mod_cache?
Accroding to the latest "nightly build log" of Chuck:
> Making in httpd-2.0-nightly
> In file included from mod_cache.c:61:
> mod_cache.h:213: syntax error before `apr_atomic_t'
> In file included from cache_storage.c:61:
> mod_cache.h:213: syntax error before `apr_atomic_t'
> In file included from cache_util.c:61:
> mod_cache.h:213: syntax error before `apr_atomic_t'
--
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.: +972-9-766-1314 P.O.B. 7004
Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
Roll of 2.0.36, WAS: RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
Posted by Sander Striker <st...@apache.org>.
Hi,
I was going to roll 2.0.36, but I want to wait for this last
worker change. Unfortunately I don't have the time to pursue
the issue now, so if someone does, please feel free to take
care of this annoying beast.
Sander
> From: Sander Striker [mailto:striker@apache.org]
> Sent: 01 May 2002 15:11
>> From: trawick@rdu88-250-035.nc.rr.com
>> [mailto:trawick@rdu88-250-035.nc.rr.com]On Behalf Of Jeff Trawick
>> Sent: 01 May 2002 14:53
[...]
>> (My apologies for not keeping up with the discussions over the past
>> days.)
>>
>> I don't see (yet) which segfault this would fix. Maybe I was hoping
>> for a fix to the wrong problem...
>>
>> If this was to be combined with a change to do a thread-join on the
>> workers even for graceless termination, then I can see how the
>> segfault caused by cleaning up a pool that the worker threads depend
>> on would be avoided. (But of course a thread-join on a worker could
>> hang for a while, depending on what a 3rd-party module is doing.)
>>
>> This change alone doesn't do much for the race between the main thread
>> cleaning up pchild and the worker threads getting dispatched and
>> realizing that they can exit and finally finishing their use of data
>> in subpools of pchild and doing the pthread_exit().
>
> Grmpf. Ofcourse, you are correct. We need the thread_join as a patch
> job. After 2.0.36 I am afraid we have to implement apr_thread_cancel...
>
> Sander
>
RE: cvs commit: httpd-2.0/server/mpm/worker worker.c
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu88-250-035.nc.rr.com
> [mailto:trawick@rdu88-250-035.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 01 May 2002 14:53
> jerenkrantz@apache.org writes:
>
> > jerenkrantz 02/05/01 00:15:40
> >
> > Modified: . CHANGES
> > server/mpm/worker worker.c
> > Log:
> > Close sockets on worker MPM when doing a graceless restart. This should
> > resolve some segfaults see when doing such restarts.
>
> (My apologies for not keeping up with the discussions over the past
> days.)
>
> I don't see (yet) which segfault this would fix. Maybe I was hoping
> for a fix to the wrong problem...
>
> If this was to be combined with a change to do a thread-join on the
> workers even for graceless termination, then I can see how the
> segfault caused by cleaning up a pool that the worker threads depend
> on would be avoided. (But of course a thread-join on a worker could
> hang for a while, depending on what a 3rd-party module is doing.)
>
> This change alone doesn't do much for the race between the main thread
> cleaning up pchild and the worker threads getting dispatched and
> realizing that they can exit and finally finishing their use of data
> in subpools of pchild and doing the pthread_exit().
Grmpf. Ofcourse, you are correct. We need the thread_join as a patch
job. After 2.0.36 I am afraid we have to implement apr_thread_cancel...
Sander