> On Oct 11, 2019, at 10:21 AM, Nikita Popov <nikita....@gmail.com > <mailto:nikita....@gmail.com>> wrote: > >> Hi! >> >> So maybe it narrows down to: >> >> Is there an essencial attempt to improve `exit()` handling from the >> userland perspective or should the focus be solely on solving the >> memory management issue pointed out in the beginning of the thread? >> >> If the scope is to also improve userland, option 3 could be the way to >> go indeed but I confess to do not be a fan of another callback >> registering thing... it feels hard to predict when you consider: >> >> ``` >> catch_exit(function(){ >> exit(); // what happens here? We still have to guarantee `exit` to >> halt at some point. >> }); >> ``` >> >> And what are the interactions with `register_shutdown_function`? I >> suppose the `catch_exit` stack has to be run before the >> `register_shutdown_function` stack? Considering the behavior in the >> docs. >> > > I think I was a bit unclear in how the catch_exit() function is intended to > work: It's not an atexit handler, it's basically a try/catch block for > exits. > > $exitExceptionOrNull = catch_exit(function() { > // Run code that may contain exit() here > }); > > or possibly even more explicitly as: > > catch_exit(function() { > // Run code that may contain exit() here > }, function($exitCode, $exitMessage) { > // This is called if an exit() occurred > });
The second option seems better, as it's a lot more obvious what code will be executed if exit() is called and what will not be. Would a set_exit_handler function be possible, similar to set_exception_handler? > > I like option 4 much more for now. It allows tackling the root issue >> and still leaves possibilities open regarding how the exception >> hierarchy could be and how the handling of `exit` could happen >> (through a catch at userspace or callback registering). >> > > I guess we should do that as the first step in any case ... everything else > would be extensions on top of that, but this would be the main technical > groundwork. > > Nikita Option 4 of course would be fine for now. Once that's done, we can decide how exits could be "caught" in the future. > On Fri, Oct 11, 2019 at 5:13 PM Marcio Almada <marcio.w...@gmail.com > <mailto:marcio.w...@gmail.com>> wrote: > >>> >>> EngineShutdown could be a special exception to the engine, being handled >> like an exception internally, but not implement Throwable and therefore not >> an exception from user-land's point-of-view. >>> >>> EngineShutdown could be added to the list of "throwables", but forbid >> instigation in user-land. >>> >> https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916 >> >> <https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916> >>> >>> No catch block would catch it, because it wouldn't implement Throwable >> nor extend Exception or Error. >>> >> >> Very elegant solution! >> >> PS: Naming things is hard, but `Throwable` could not have been a >> better choice in retrospect. Ty ;) Thanks! Every once-in-a-while I manage to name something correctly! >> >>> Aaron Piotrowski >>> >> >> Márcio Aaron Piotrowski
