httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: [PATCH] get threaded MPM to terminate
Date Tue, 24 Apr 2001 21:33:23 GMT
rbb@covalent.net wrote:
> 

> 
> Not writing to the pipe_of_death is just a bug.

Agreed. Design bug or code bug?  (not that it matters)  

>
> 
> This is the problem with the current logic.  Remember, that Manoj and I
> spent a LOT of time 

Yes.  Thank you both.  It was a very good starting point, it was close
to being right, and the Pipe of Death was an elegant and necessary
invention IMO.

>    getting this right, and it worked for a very long time, 

huh?  it had timing windows for a long time.  Now it's time to move on,
and eliminate them once and for all.

>   which is why I am questioning that the algorithm is really wrong, I
> believe it is a bug, not a logic error.

what's the difference?   does anybody care?

> 
> Can't this whole thing be solved by having the process that was woken up
> by the pipe_of_death set workers_may_exit before releasing the poll lock?
>

I know this patch works, even if the parent only sent one character on
the pipe of death.  

What I haven't pondered very much is the loop sending a character per
process.  I don't know if that's absolutely air tight.  It may be. 

> BTW, if the parent is signalling a graceful shutdown, the child process's
> signal handler should never be awoken until all the other threads are
> gone.

hmmm...how can you tell for sure when all the worker threads are gone,
unless you are the signal thread and you do a pthread join?

> 
> The problem I have with this, is that workers_may_exit is specifically a
> local variable.  

yeah, but we're programmers, and we have the technology to change that.  

>                  The parent process should not be touching it.  It is up
> to the process how it is going to go away.  

Which process decides whether the user wants a graceful shutdown vs.
quick -n- dirty shutdown vs. a restart?

>   The fact that this patch moves
> it to the parent's job to set workers_may_exit is incorrect.
>

I respect your opinion, but disagree.  This patch works, and it has a
really nice side benefit, as well.

I think it's great that those death codes are in the scoreboard for
admin reasons as well as for sealing up the timing windows.  mod_status
could display them, and the admin would have a better view of what
Apache is up to internally in our long running download scenarios, for
example.  The ability for admins to see this kind of information will be
important for the success of any threaded mpm.

Greg

Mime
View raw message