Re: Question about socket ext. file descriptors

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