Re: cvs: php4 /ext/standard file.c

At 17:08 23/12/2000, Sascha Schumann wrote:

On Sat, 23 Dec 2000, Zeev Suraski wrote: At 16:56 23/12/2000, Stanislav Malyshev wrote:

SS>>     The rationale behind SIGXFSZ seems to be that a process
SS>>     should be terminated, if it exceeds process limits.

If so, shouldn't we comply with that thought and let the process die? Like, if Unix standards guys think that's right for a process to die in this case, they should know better?

I'd be in favour of catching it and displaying a PHP-level fatal error. There's nothing magical about catching signals...

    And what happens, if the authors of mod_perl, mod_dtcl,
    mod_snake have the same idea?  How is a PHP-level handler
    supposed to deal with SIGXFSZ generated by other modules?

(a) Anything will be better than the current situation, in which data can end up being lost without any indication. (b) As it is possible to write to files using PHP functions (such as fwrite()), it's possible to get hit by this signal right now as well. Handling it properly would be a good idea at any rate. (c) Even if you play what-if, IMHO, weighting the consequences, catching the signal has no real drawbacks. I guess it's possible that some complex/advanced module will use this signal to detect that the filesystem is full or that the write limit has been reached, and do something about it (free space?), but I think that's pretty unlikely. Most module will simply display it as an error as well, if they handle it at all. So worst case - we'll be overriding their error reporting function, or they'd be overriding ours. No biggy in both cases. (d) If you think that it's still likely we'll interfere with the core behavior of other modules, we can always turn on our signal trapping on request startup and restore the original signal handle on request shutdown. I don't think it's necessary though. Zeev

--

Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/