[PATCH 1 of 2 STABLE] worker: be silent if killed by the main process

Jun Wu quark at fb.com
Sat Apr 22 16:54:50 EDT 2017


Excerpts from Jun Wu's message of 2017-04-22 13:34:52 -0700:
> Excerpts from Yuya Nishihara's message of 2017-04-23 00:55:45 +0900:
> > On Fri, 21 Apr 2017 21:31:05 -0700, Jun Wu wrote:
> > > Excerpts from Yuya Nishihara's message of 2017-04-22 12:18:52 +0900:
> > > > > The new plan is to use SIGUSR2 to "kill" workers, SIGUSR2 handler is to do
> > > > > sys.exit. So "killed!" is removed and traceback is kept.
> > > > 
> > > > What's the key difference from just making SIGTERM handler silent?
> > > 
> > > No "killed!" is printed. And users killing them manually will still get
> > > "killed!".
> > 
> > I think that is the same sort of problem as SIGINT, which is no
> > "interrupted!" is printed right now but we can't make worker processes
> > print it. I guess both SIGINT and SIGTERM issues can be solved in the same
> > way.
> 
> I finally get it. tl;dr I prefer moving SignalInterrupt to dispatch.py and
> will do that.

But I suspect if that works. Since the signal could arrive before the main
"try" block in the worker process. "killed!" may still be printed because
it's caught by dispatch.py and the worker "try except" code is not executed
yet.

I also think the current worker code could escape the "always os._exit"
assumption if a signal hits before "try".

So it seems we want to set a global exception handler before calling
os.fork(). I'll do that instead.

> The two approaches only differ in the case where a manual SIGTERM hits a
> worker, the SIGUSR2 way will print "killed!" as it was before. But I think
> not printing "killed!" in all cases is cleaner.
> 
> > That said, there should be no problem using SIGUSR2 for more explicit
> > control of worker processes.


More information about the Mercurial-devel mailing list