On Thu, 2002-02-21 at 18:09, J Smith wrote:
>
> I'm all for fixing this extension up to make it better,
Great!!!
> but I'm a little
> concerned with totally dropping the fd_* functions. How would you mimic
> their use in something like a multiplexing using a blocking call situation
> after the change? I have no idea how it can be done without using the fd_*
> function. (But then again, I'm used to using the FD_* macros in C, so maybe
> there's better way in PHP.)
Well, since you know the C-API, lets look at if from the C socket API
perspective. select() is designed to take 3 arrays. The problem with
arrays is that they take up memory and processing time. In application
space this really isn't a problem, but in the kernel, every saved byte
counts. To optimize this they emulated arrays using bit masks. Another
optimization they performed is to have you pass the highest file
descriptor + 1 into select. (that way they only process part of the bit
mask.)
What I am getting at, is that FD_* was an interface designed strictly
for kernel performance. Direct manipulation of these low level values
does not really belong in a high-level language.
The method that makes the most sense is to use php arrays in place of
the fd masks. Everything would work exactly the same, except it would be
much easier to interface, it would be less buggy, and require less code.
By the way, the bug with the socket_fd_functions, is that it may set
your maximum file descriptor incorrectly, and this would cause you to
miss events occurring on ready sockets. (This occurs anytime you call
socket_fd_clear() on a socket, or if you don't add sockets in order they
were opened ex. 3, 1, 2 will cause you to lose file descriptor 3.
example
--------
<?php
// ...
$read_flds=array($socket1, $socket2, $socket3, $socket4, $socket5);
$write_flds=array($socket6, $socket7, $socket8);
$except_flds=array($socket9);
// Wait on sockets specified in arrays, and modify them to contain
// sockets that are ready
$retval = socket_select($read_flds, $write_flds, $except_flds, 1);
//Perform actions on sockets waiting to be read
foreach($read_flds as $read_sock)
perform_read_action($read_sock);
//Perform actions on sockets waiting to be written
foreach($write_flds as $write_sock)
perform_write_action($write_sock);
//Perform actions on exceptions
foreach($except_flds as $except_sock)
process_exception($except_sock);
// ...
?>
> Just wondering, because I acutally use this extension in a multiplexing
> kind of way with indefinite socket_select blocking and multiple clients and
> all that jazz already. Yeah, I know it's experimental and stuff, but it has
> yet to fail, even with my "daemon" script running for weeks on end under a
> fair load. I use the socket functions in a search engine that's constantly
> listening for connections using socket_select, and the socket_fd* functions
> are used quite a bit, hence my concern. (Not that I'm adverse to the
> change, 'cause I'm sure I'll cope, but I'd like to know if it will be
> possible to port my existing stuff over to the new API.)
I would like to see this extension become stable so that people can
start relying on somewhat frozen behavior.
To answer your question It should be pretty easy to port your code to
the newer API.
I appreciate hearing concerns like this, and I hope you and others
continue to speak up. : )
-Jason
>
> J
>
>
> Jason Greene wrote:
>
> >
> > 2. Get rid of socket_fd_*.
> > -----------------------------
> >
> > It makes little sense to make fd masks available to the user, because
> > this can be much easier to handle by using arrays.
> >
> > This will fix the max_fd code that attempts to calculate the highest
> > file descriptor in the fd_set.
> >
> > Select would then look like
> > socket_select (array read_socks(), array write_socks(), array
> > except_socks(), int tv_sec, int uv_sec)
> >
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Jason T. Greene
Internet Software Engineer
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Use PHP: http://www.php.net
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
