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