@artemis @whitequark @thephd yes, from what i read, this seems to be the motivation behind this choice of error handling. the idea is that even if malloc fails, there is still some page returned to the client, instead of everything burning
@confusomu @whitequark @thephd oh thats a bit cursed
@confusomu @whitequark @thephd i mean lua does also use setjmp/longjmp for error handling so maybe not the most cursed conceptually, but maybe theres a difference in implementation. ive read how lua does it and it seemed well-conceived to me
@artemis @confusomu @thephd as I understand it, the difference is that Lua is written more or less like embedded code, and PHP is written like PHP
@confusomu @artemis @thephd I think there's a good way to solve this: just pass the fd to a new process. you could even call exec directly, it doesn't allocate
(you might have to pre-allocate the arguments to exec but this is way simpler than what I hear they're doing)
@whitequark @artemis @thephd this seems much simpler than trying to clean up from every call site, and you could still return something for the partially completed request.
however, this wouldn't work for thread safe PHP (which apparently is a choice when using PHP with Apache, but FastCGI uses non-thread safe PHP) as it would drop other connections in the same process, unless you save their state (which seems extremely brittle)
@confusomu @artemis @thephd I feel like "we're deprecating thread-safe PHP" might be a better way to address this issue than a never-ending stream of OOM fixes nobody has the bandwidth for, but I guess there are probably big hosts which want the former. Oh dear.