"Roy T. Fielding" wrote:
>
>
> The reason I have no confidence in the pipe of death as a solution is
> simply that I haven't seen it work yet under stressful conditions,
that's why I asked people to beat up on threaded, esp.
shutdown/restart. I'm hearing good reports so far (knock on wood) about
shutdown/restart. Due to that and due to gaining an understanding of
the design because of my recent foray into threaded, I'm fairly
confident in the Pipe of Death.
That said, I'd prefer to see the PoD disappear for performance reasons,
if we can work thru the issues. But IMO the first priority is making a
stable, generally usable version of threaded available.
> and
> when I look at the code it just seems like something is wrong. Like,
> why is it that workers_may_exit is never set to zero?
it's init'ed to zero...
> Is it merely
> because only the workers ever set it to 1, and once that happens it is
> on the road to exiting the process in any case?
yessir
>
> And why does each worker grab a mutex before checking the pipe of death?
> All that a worker does is check to see if there is a character on the
> pipe and, if so, it tells all of the workers to exit. So why does it
> matter if more than one worker gets inside that exclusion zone? *shrug*
yet another good question. I'll take a crack at it:
when the parent decides to shut down or restart, it writes one character
per process on the PoD. If multiple worker threads within a given
process are allowed to each eat a character, some other process may not
be woken up . This stall only occurs under very light loads (e.g.
developers running tests).
This mutexing is outside of the hot path, so *shrug* here too. I just
committed a comment about "why the mutex" for posterity, so if it's
wrong, please jump all over me :-)
Greg
