ID: 34380 Comment by: andreas at softwaredesign dot se Reported By: jim at centerfuse dot net Status: Open Bug Type: Feature/Change Request Operating System: FreeBSD PHP Version: 5.0.4 New Comment:
This bug really needs some attention. It seems that as of today, there is no way to tell whether a stream had a real error, or it just got interrupted by a signal. This makes writing PHP daemons managing child processes using proc_open and stream_select virtually impossible when the daemon also needs to be able to intercept signals (as a daemon preferably would). The stream_select *will* get interrupted by signals, and as the bug report states, there is no way to tell if the interruption was because of a signal, or if something really scary happened. This leads us to the one and only horrible solution: ignoring all errors that stream_select returns, as we presume that the system call was just interrupted. Previous Comments: ------------------------------------------------------------------------ [2005-12-01 06:04:01] jim at centerfuse dot net Just wondering if there's any word on this. I'm having trouble with the sockets module crashing my PHP daemon (bug report will come when I figure out what's going on, and after I make sure it's not my fault), and I'd like to move to streams. However, the lack of stream_last_error() is making this a bit difficult. ------------------------------------------------------------------------ [2005-09-05 22:42:02] jim at centerfuse dot net Description: ------------ In order to determine if a function such as stream_select() returning false was a significant error, or just an "interrupted system call" (which can happen due to other signals interrupting the select), it'd be quite useful to have a stream_last_error() function that allows us to check the error code returned by stream_select(). ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=34380&edit=1
