On 7/30/08 11:54 AM, "Stanisla Malyshev" <[EMAIL PROTECTED]> wrote: > I have a couple of questions about the patch: > 1. Why allocate fixed-size buffer via individual malloc's on each > activate and free it on each deactivate? Won't it be better to just > allocate it once and use it?
I'll take a look at this. I can't think of a reason not to avoid the alloc's per request. > 2. Why define own SIG_UNEXPECTED - we already have UNEXPECTED macro in > the engine? Good question. Trying to remember.... Ok yeah, it's not coming to me. Unless it comes randomly into my head I'll switch this over. > 3. I understand that ZEND_SIGNALS is disabled whenever ZTS is on. > However, in the code I see parts where under ifdef ZEND_SIGNALS there's > still checks for ifdef ZTS. Why is that? Is it planned to be implemented > on some stage? I was initially planning to implement ZTS, however the more I learned the harder it became. The first issue being that not every scope implementing the blocking macros has implemented or fetched TSRMLS data. Many places in zend_alloc.c for example fail with the new macro's because of the missing rsrc_id. Also, while this will eventually add some safer ZTS blocking protection it will definitely come at a performance cost instead of the gain we might see in non-zts mode. I wasn't ready to jump in a start changing too much of zend for this to be possible. Most of these are in zend_alloc.c and zend_hash.c. In addition we'd need also need to figure out how manage signal delivery to the right thread. This wasn't something we really needed so I put it off. Instead of yanking all the ZTS references out of the code I left them in for future use. It seems that Pierre was interested in working on support under windows and maybe someone will want to help with non-windws ZTS as well. > 4. Why we try to handle SIGTERM and SIGQUIT - aren't those supposed to > kill the process anyway? This depends on what the SAPI is doing. In Apache 1.x SIGTERM, as well as SIGINT, will both trigger a full php shutdown via Apache's handler, which if long jumped into from within a critical section will be very likely to segfault. SIGQUIT is usually set to SIG_DFL by Apache 1.x but there's no guarantee what this will be in any other SAPI so the safest route seems to be to include these, I could be wrong. The real risk is that pressing CTRL-C or issuing a kill might cause an actual exit or coredump to be delayed, or not happen at all, if we were truly blocked or stuck within a critical section. Thanks for the useful feedback! -lucas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
