On Sat, Mar 11, 2017 at 1:32 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > On a related note. At Booking.com in our web applications we don't run > destruction beyond just destroying the Plack $env, then we > POSIX::_exit(). See https://github.com/unbit/uwsgi/pull/1392/files & > https://github.com/unbit/uwsgi/issues/1384 for why, but tl;dr: With > forked processes it creates a CPU/Memory DoS attack on the kernel as > it frantically tries to unshare all the pages whose refcounts change. > > So uWSGI has an option now to simply skip the perl_destruct() & > perl_free() phases, which from my looking at the source & testing it > seemed like the sane solution: > https://github.com/avar/uwsgi/blob/bafc14c80771a2c55063c3c9cc9c9dd0377a0294/plugins/psgi/psgi_plugin.c#L860 > > I can't think of a use-case for this, but is it a good idea to provide > some alternative to POSIX::_exit() in this case, i.e. is there some > subset of perl_{destruct,free}() that we could run that wouldn't free > everything, but e.g. just enough to run any DESTROY handlers? > Currently if we have some DESTROY handler hanging off anything but > $env it simply won't execute when we teardown the process. > > I don't know if that's possible or even a mad idea, but since you're > poking this code I thought I'd bring this use-case to your attention. Perl already has a concept of destruct level, current valid values are 0, 1, and 2. 0 destructs much of the interpreter and all objects, this is the default on unthreaded perls. 1 destructs a bit more of the interpreter, in particular the stashes. This is the default in an embeded perl with multiplicity enabled. 2 destructs absolutely everything, including non-object cycles and the global string table. threads.pm sets it to this value. I'm not sure what the value for PL_perl_destruct_level is in your particular case, lowering it may help. I can imagine introducing a -1 level that does little more than run END blocks and flush IO buffers. LeonThread Previous | Thread Next