On Thu, 29 Mar 2001, Lars Torben Wilson wrote:

> 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
> me):
> 
<snip>

Nope, you aren't missing anything. The extension, I admit, is breaking
some rules -- negative values instead of false for return values for
example. OTOH, it *is* perfectly possible, for example, that
socket() might return 0, which evaluates to false and is yet a valid file
descriptor.

The reason for returning file descriptors instead of resources was
primarily select(). One thing I was considering doing was writing a file
descriptor table (an fd_set perhaps) that keeps track of the open file
descriptors, and at the end of the request (PHP_RSHUTDOWN...) closes all
of the open sockets.

I'm currently updating my CVS tree so I can update the current source with
something to make sure that stuff opened here is closed at the end of
it. For this, I'm not too fond of going the resource route for it, simply
because I know people are more familiar with the C interfaces to
socket() and friends (I know I'm not alone in this, but if I seem to be,
feel free to speak up now).. so it makes the interfaces more familiar to
people who would want to use it (and since I tried to keep the interfaces
as similar as possible, it also means that people don't have to go running
to the manual for everything except for the few oddities .. 'man socket'
will tell you all you need to know about socket() on any decent *nix
system.)

I'm attempting to compile my fix for it now, will commit soon if compile
goes well.

Chris



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