Have you measured the performance impact? This should be a "solvable" problem, and if it takes a while to find a nice solution, we could just disable signal handling by default but leave the rest of pcntl enabled by default?
IMHO using ticks isn't a very good solution (it's basically another hack on top of an old hack :-) because you'd have to wrap "signal-enabled" code in a declare section, and you wouldn't be able to use ticks for anything else. - Stig Jason Greene wrote: > > I apologize for the late reply, my time for the last month has been consumed by > employer issues. Things should be getting back to normal again soon. I am > a major +1 on the cli, though I have some concerns about pcntl being enabled by > default. > > Currently, my signal trapping method uses a handler that is not intended for the > way I am using it. I use the debug statement handler, which generates a performance > impact. (Though I have not measured it) Quite a while ago, I had discussed briefly > with Andi, and Zeev about using a better hook. I was mainly after some form of a call > back in the main execute loop. It was suggested that I could use ticks, but I do not >think > this is a good idea because it would make signals and ticks incompatible with each >other. > > The signal replay code is as efficient as I could make it, so I do not think it >would cause > to much of a performance hit if it had a way into the loop. If it is undesirable, we >could > only impact the execute loop if the cli (or maybe even cgi) sapi is chosen. I could >do some > test cases if that would help. Zeev, Andi What do you think? > > I am up to discussion on this, so any ideas would help. > > Thanks, > -Jason > > ----- Original Message ----- > From: "Stig S. Bakken" <[EMAIL PROTECTED]> > To: "Andrei Zmievski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Monday, October 15, 2001 7:05 PM > Subject: Re: [PHP-DEV] always building executable > > > "Stig S. Bakken" wrote: > > > > > > Andrei Zmievski wrote: > > > > > > > > On Mon, 15 Oct 2001, Stig S. Bakken wrote: > > > > > If you make it a normal extension, and you don't have --enable-pcntl in > > > > > your configure line, the right thing would be to include it in the cli > > > > > version but not the apache version or whatever. So either we need a > > > > > mechanism for conditionally including extensions in a build (ka-yuck), > > > > > or it has to be moved. > > > > > > > > But what about other extensions that only make sense with cli version, > > > > like readline? > > > > > > Hm, good point, there are lots of these. So basically we need another > > > library aside libphp4.la for each sapi backend, and put the extensions > > > in question into the right one of these. > > > > That was really a write-only reply. :-) > > > > What I mean is something like this (SAPI means selected SAPI backend): > > > > libphp4core.la - "core" library (main, libs, expat, regex etc) > > libphp4ext.la - extensions in all sapi backends > > libphp4ext_apache.la - extensions for use with sapi/apache > > sapi/apache/libphp4.la - final Apache library > > > > - Stig > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > To contact the list administrators, e-mail: [EMAIL PROTECTED] > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
