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.


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,
> > 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|
> > >| |
> > >|Ph: 1.604.709.0506                             [EMAIL PROTECTED]|
> > >+----------------------------------------------------------------+
> > >
> > >--
> > >PHP Development Mailing List <>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>|Torben Wilson <[EMAIL PROTECTED]>                    Adcore Finland|
>| |
>|Ph: 1.604.709.0506                             [EMAIL PROTECTED]|

PHP Development Mailing List <>
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