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.

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

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]
>> >
>>
>>--
>>+----------------------------------------------------------------+
>>|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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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