Front page | perl.perl5.porters |
Postings from March 2017
On Sat, 11 Mar 2017 04:33:24 -0800, 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?
Well, there is sv_clean_objs. I think it is an API function.
> 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.
Iâm not exactly poking it. I *have* poked it in the past, so I thought I could give some input (which I fear proved no more helpful than what was already said).
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=32714
Thread Previous