[tarantool-patches] [kostja at tarantool.org: Re: [PATCH v2 3/3] box: pass signal to on_shutdown triggers]

[Konstantin Osipov]

----- Forwarded message from Konstantin Osipov <kostja at tarantool.org> -----

Date: Wed, 5 Dec 2018 00:55:47 +0300
From: Konstantin Osipov <kostja at tarantool.org>
To: tarantool-patches at freelists.org
Cc: Serge Petrenko <sergepetrenko at tarantool.org>
Subject: Re: [tarantool-patches] [PATCH v2 3/3] box: pass signal to on_shutdown
	triggers

* Serge Petrenko <sergepetrenko at tarantool.org> [18/11/26 17:26]:

> Start passing signal which caused termination to on_shutdown triggers.
> 
> Closes #1607
> 
> @TarantoolBot document
> Title: Document box.ctl.on_shutdown triggers
> on_shutdown triggers may be set similar to space:on_replace triggers:
> ```
> box.ctl.on_shutdown(new_trigger, old_trigger)
> ```
> The triggers will be run when tarantool exits either normally, or due to
> receiving a signal `SIGTERM`, `SIGINT`, `SIGHUP`.
> The signal which caused termination (if any) is available to the trigger
> as 1st parameter.

Unfortunately this doesn't capture fatal signals- SIGSEGV and
SIGABORT. Not to mention that the triggers are not invoked on
these signals. Without these signals passing the signal number is
not of much use. Let's drop this altogether. And not forget to
document cases when on-shutdown triggers are *not* invoked in the
docbot request.

As to limitations, it's quite OK you can't call 'box' methods on
shutdown, but I believe the user expected to be able to yield on
shutdown, i.e. use the app server.
Can we change the timing of trigger invocation to "before ev loop
break" ? 

I've been wanting to stop using exit() and atexit handlers for
shutdown for a long time for two reasons:

- their behaviour in a multi-threaded program is not defined and
  not documented. When atexit() is invoked replication and other
  threads still run on Linux, but I wasn't able to find any
  confirmation in POSIX that this is standard. POSIX says that
  threads cease to exist on return from main(), but doesn't make
  it clear exactly when :). 
- reasoning about the way atexit() handlers work with the event
  loop is very hard as well

I'd like to propose a solution for this issue.
We could fiber_call() a fiber which would in turn call
ev_loop_break(). This would make the shutdown cleanups very simple
and straightforward, as well as allow using yields in shutdown
triggers.  

Could you please prepare a patch for it? We could perhaps even
reuse sched fiber for this purpose, after a few tweaks, so that we
don't have to reserve an extra fiber stack for the purpose.

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov

----- End forwarded message -----

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov