Re: Question about socket ext. file descriptors

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): PHP_FUNCTION(socket) { zval **domain, **type, **protocol; int ret; if (ZEND_NUM_ARGS() != 3 || zend_get_parameters_ex(3, &domain, &type, &protocol) == FAILURE) { WRONG_PARAM_COUNT; } 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 AF_INET"); Z_LVAL_PP(domain) = AF_INET; } if (Z_LVAL_PP(type) > 10) { php_error(E_WARNING, "invalid socket type specified - assuming SOCK_STREAM"); 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 <torben@php.net> Adcore Finland| |http://www.coastnet.com/~torben http://www.adcore.com| |Ph: 1.604.709.0506 torben@adcore.com| +----------------------------------------------------------------+