On Thu, Feb 20, 2003 at 05:11:55PM +0100, Wojtek Meler wrote:
> On Thu, Feb 20, 2003 at 05:48:29PM +0200, Zeev Suraski wrote:
> > At 17:38 20/02/2003, [EMAIL PROTECTED] wrote:
> > >----- Original Message -----
> > > > I looked into the bug report, and it is true that
> > > > BLOCK_INTERRUPTIONS
> > > > should indeed block SIGPROF. I'll fix this in the weekend.
> > >
> > >I'm not sure if after unblocking interruptions PHP will get SIGPROF ...
> > >it could cause looooong scripts. I'd rather use EG(timeout). I'm using
> > >it now and it's working.
> >
> > EG(timeout) is a horrible option (I wrote both, SIGPROF is by far
> > superior). I'll try to implement a solution that won't lose the SIGPROF.
>
> It's possible to call zend_bailout if EG(timeout) is set in
> UNBLOCK_INTERRUPTIONS macro. But it doesn't solve main problem - it is
> not safe to just skip the stack - even PHP use locks (TSRM) and its
> memory allocator also use malloc/realloc/free which use locks, so it isn't safe.
>
> External libraries uses memory structures which can't be freed if
> paritialy modified (because SIGPROF stops modification in the middle).
> Trying to free them by PHP resource mechanism can cause SIGSEGV, busy loops etc.
> Not freeing them we loose memory ...
>
> I strongly recommend to stop using zend_bailout on timeouts (it's better
> to exit - it will not hang ;)
zeev, remember we discussed the very same thing last year (or
the one before) at linuxtag in frankfurt?
i also think that exit() would be the "clearest" thing. but
it won't help in any threaded environment - so it's not an
option.
thing is - no matter how "clever" it is implemented - calling
longjump from a signal handler is calling for trouble unless
everybody involved beeing very careful about their "critical regions".
especiqal non-threadsafe libs are very likely to not even
have a concept what a critical section is...
re,
tc
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
