Zeev Suraski writes:
> Note that the situation isn't as bad as you thought - it's not that it's 
> not using the resource mechanism.  It is, if it wasn't, we'd be getting 
> loads of complaints from people running out of descriptors very 
> quickly.  It just uses old, PHP 3 style resources, of type 
> IS_LONG.  They're still destroyed when the request ends, so it's all safe 
> and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which 
> are actually destroyed when they're no longer needed.  It's a good idea to 
> update this code, but it's not very dangerous the way it is now.

This doesn't look like what I remember from PHP...for instance, send()
definitely isn't using any form of resources.

> Lars - apparently you got it wrong;  The integers you are getting are *not* 
> file descriptors.  They're resource handles, of type IS_LONG.  They might 
> accidentally correspond to the file descriptors, but it'd be complete 
> coincidence.  In short, regardless of whether we upgrade the file functions 
> to use IS_RESOURCE resources or not, what they return cannot be relied upon 
> as file descriptor numbers, simply because they're not.
> I hope that clears it up...
> Zeev

I hate to argue with you :) but this sure looks like it's passing back
the descriptor (I could be missing something so if I am just shoot

        zval **domain, **type, **protocol;
        int ret;

        if (ZEND_NUM_ARGS() != 3 || 
            zend_get_parameters_ex(3, &domain, &type, &protocol) == FAILURE) {
        multi_convert_to_long_ex(3, domain, type, protocol);

        if (Z_LVAL_PP(domain) != AF_INET && Z_LVAL_PP(domain) != AF_UNIX) {
                php_error(E_WARNING, "invalid socket domain specified - assuming 
                Z_LVAL_PP(domain) = AF_INET;
        if (Z_LVAL_PP(type) > 10) {
                php_error(E_WARNING, "invalid socket type specified - assuming 
                Z_LVAL_PP(type) = SOCK_STREAM;
        ret = socket(Z_LVAL_PP(domain), Z_LVAL_PP(type), Z_LVAL_PP(protocol));
        RETURN_LONG(((ret < 0) ? -errno : ret));

> At 14:06 29/3/2001, Andi Gutmans wrote:
> >Lars,
> >
> >I understand what you're saying but there is one important problem with 
> >the current implementation which I think outweighs everything else. The 
> >fact that right now you are likely to leak file descriptors. This is very 
> >bad especially as Apache processes live for many requests. If the person 
> >forgets to close the socket(), his program exits before it reaches that 
> >code, or someone presses the STOP button on his browser PHP will leak file 
> >descriptors. Very quickly the Apache process will have no file descriptors 
> >left. This has to be fixed. I prefer seeing it fixed with resources but in 
> >the least it should be fixed not to leak fd's even if you go with the 
> >integer fix implementation. But it is not very PHP to do that. You already 
> >have an fd resource as far as I know in ext/standard so you can use that.
> >
> >Andi
> >
> >At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote:
> >>Andi Gutmans writes:
> >> > Why do you need to rely on such behavior? Are you trying to do something
> >> > naught? :)
> >> > I think in general it's not a good idea to rely on the value and type of
> >> > resources (even though this is an integer).
> >> > I'm not quite sure why it returns integers and not resources. Looks like a
> >> > bad thing to me as the extension can easily have file descriptor 
> >> leaks. The
> >> > socket should really be saved either in the resource list or in a socket
> >> > extension local list in order to be able to cleanup at shutdown.
> >> > I think in the meanwhile you should assume it might change to using 
> >> resources.
> >> >
> >> > Andi
> >>
> >>That was what I had been thinking, until I started using
> >>select(). Since select() needs to know the max fd # you're working
> >>with, it's easy to have it as an int. Unless, of course, select()'s
> >>PHP implementation is updated to automatically take this into
> >>account. I could always parse the 'Resource #n' string, but that is
> >>clumsy. There are other things as well, but this is the first one to
> >>come to mind.
> >>
> >>I totally agree that in general it's a good idea to use resources and
> >>leave the housekeeping to PHP, but in situations like this I wonder if
> >>the usefulness of the int descriptor doesn't outweight the benefit of
> >>turning it into a resource.
> >>
> >>Basically, I guess I'm approaching socket programming in PHP from a C
> >>perspective, and thinking that others might as well. Having the
> >>descriptors as ints does tend to relieve some aches, but it might be
> >>more PHP-like to move that behind a resourse type and let PHP keep
> >>track of the highest fd (for stuff like select()).
> >>
> >>I guess I also sorta think that when you start messing around with
> >>stuff like fd_set() and select(), you expect to be given enough rope
> >>to hang yourself with. :)
> >>
> >>I've no particular leaning to one side or the other, but I'd like to
> >>know what people think about this.
> >>
> >>
> >>Thanks again,
> >>
> >>Torben
> >>
> >> > At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote:
> >> >
> >> > >At present, the sockets extension uses integers as file descriptors
> >> > >(e.g. socket() return value). At first I thought maybe they should
> >> > >have been resources until I tried writing some socket code, when I
> >> > >realized that it's easier under many circumstances for them to be
> >> > >ints. Is this going to be behaviour that can be relied upon?
> >> > >
> >> > >Thanks,
> >> > >
> >> > >Torben

|Torben Wilson <[EMAIL PROTECTED]>                    Adcore Finland|
|http://www.coastnet.com/~torben            http://www.adcore.com|
|Ph: 1.604.709.0506                             [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]

Reply via email to