Slight correction -- the fix is actually something more like this (at least currently):
If the user passes "null" for the sec argument, pass NULL to select() for tv. I think it would probably be better to handle it with the following conditions: 1. if the user passes null for both sec AND usec, pass NULL to select(). However, if either are non-null values, set tv.sec and tv.usec accordingly. This is to account for the unlikely event where the user wants to determine sec and usec dynamically. This way, they can also pass NULL for sec and a value for usec and still have the non-blocking call based on usec, while passing 0 for sec. 2. if the user passes null for sec and leaves off the usec argument, pass NULL to select(). This is sort of how the original worked, but if you passed null for sec and a proper value for usec, usec wouldn't be used and NULL would still be passed to select(). The above case would handle this, as usec could still be used. 3. if the user leaves off both sec and usec, pass NULL to select(). That would seem to be a bit more friendly than the current 4.1.2 behaviour, and would account for passing null as sec and a value for usec. J J Smith wrote: > > I think I see bug number 1... > > The system call for select() you to perform an indefinite blocking call if > you pass NULL as tv, but PHP's socket_select() doesn't seem to have that > feature. (It did in previous versions, from sometime in 4.0.7dev and up. I > caught that bug originally, actually.) > > The old fix is still a valid one -- if the user doesn't pass arguments sec > and usec, pass NULL as the tv argument to the system select() call. I've > implemented it in last night's snapshot and it seems to work fine. > (Although I'm having a bitch re-writing our sockets stuff -- I have no > idea how to use the arrays yet versus the file descriptors, but I'll > report as I go.) > > J > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
