Re: [PHP-DEV] FD_SETSIZE limitation
Hi, That's the reason why I started writing an ext for PHP that would implement epoll() on linux, and stuff-with-ws2 on Win32. However I don't mind making this a patch to the stream ext. Basically I get the following functions: consts: STREAM_POLL_IN (read) STREAM_POLL_OUT (write) STREAM_POLL_ONESHOT (other options exists on epoll, but are not portable. Some, like "oneshot" can easily be emulated) functions: resource stream_poll_create() bool stream_poll_destroy(resource $poll) array stream_poll_wait(resource $poll, int $timeout,int $maxevents = -1) bool stream_poll_add(resource $poll, stream $socket, int $wait_flags) bool stream_poll_mod(resource $poll, stream $socket, int $wait_flags) bool stream_poll_del(resource $poll, stream $socket) The goal is to use epoll() on linux, weird win32 stuff on win32 (thingie that converts socket to handler, then allows to use waitmultiple on that), kqueue on BSD and fallback to select on all other operating systems so those functions can be used anywhere. Anyway I was initially planning to use that internally, then maybe release it on pecl, it makes more sense to be inside ext/stream (I guess), so if anyone want to see it faster than that, why not. This can also be made OO, however the current stream ext has nothing OO, so I'm not sure it would make any sense. Anyway feedback about this is welcome, I've been wanting to write this for pinetd (those who heared about a PHP DNS Daemon should know what I mean) as using select() can become a problem when you want to handle a *lot* of clients. I am a bit demotivated, however if there is interest into this, or even if it can make it into ext/stream, I would be more than happy to finish/release that. Mark Le vendredi 20 février 2009 à 12:02 +0900, Moriyoshi Koizumi a écrit : > Robin Burchell wrote: > > On Thu, Feb 19, 2009 at 10:24 PM, Andrei Zmievski > > wrote: > >> Can someone explain why ext/sockets and also stream socket functions care > >> about FD_SETSIZE? > > > > They care, because they use the select(2) syscall, which cares about > > FD_SETSIZE. > > > > select(2) itself can handle more fildes than FD_SETSIZE on Linux at least. > > Moriyoshi > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FD_SETSIZE limitation
Robin Burchell wrote: > On Thu, Feb 19, 2009 at 10:24 PM, Andrei Zmievski > wrote: >> Can someone explain why ext/sockets and also stream socket functions care >> about FD_SETSIZE? > > They care, because they use the select(2) syscall, which cares about > FD_SETSIZE. > select(2) itself can handle more fildes than FD_SETSIZE on Linux at least. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FD_SETSIZE limitation
That's because struct fd_set, which is manipulated by FD_SET, is a struct that contains a fixed-size array. Moriyoshi Andrei Zmievski wrote: > Can someone explain why ext/sockets and also stream socket functions > care about FD_SETSIZE? > > # define PHP_SAFE_FD_SET(fd, set) do { if (fd < FD_SETSIZE) FD_SET(fd, > set); } while(0) > > On Linux, it's not a hard limitation imposed by the kernel. It's > configurable via sysctl. > > -Andrei > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FD_SETSIZE limitation
On Thu, Feb 19, 2009 at 10:24 PM, Andrei Zmievski wrote: > Can someone explain why ext/sockets and also stream socket functions care > about FD_SETSIZE? They care, because they use the select(2) syscall, which cares about FD_SETSIZE. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FD_SETSIZE limitation
Can someone explain why ext/sockets and also stream socket functions care about FD_SETSIZE? # define PHP_SAFE_FD_SET(fd, set) do { if (fd < FD_SETSIZE) FD_SET(fd, set); } while(0) On Linux, it's not a hard limitation imposed by the kernel. It's configurable via sysctl. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.9RC3 Testing
The third and final release candidate of 5.2.9 was just released for testing and can be downloaded here: http://downloads.php.net/ilia/php-5.2.9RC3.tar.bz2 (md5sum: 11dac673bc41fe607ddae680f4ae10ea) http://windows.php.net/downloads/qa/php-5.2.9RC3-Win32-VC6-x86.zip (sha1: 5150afad0bc1760c027b5a27f1727eee3a41b7b2) There were a few more changes since RC2, so to make sure that nothing slips by and no new regression are introduced RC3 is being tagged. If no critical issues and/or regressions are identified in the coming week, the final will be released next thursday. Please check the code against your apps to make sure everything is working properly. At this time I would like to ask all developers to hold-off on any commits to the 5.2 branch unless they address regressions or introduce security fixes. Ilia Alshanetsky PHP 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
That's a good point we need to make sure that main.c INI values match those of the production INI file. There are A LOT of installs that operate without an INI file. I'd say it's usually ini-dist that matches the main.c value... but the issue in this case is that ini-recommended (which is generally taken as 'ini-production' by the community at large) throws warnings that are not thrown by default, which seems pretty weird to me. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
That's a good point we need to make sure that main.c INI values match those of the production INI file. There are A LOT of installs that operate without an INI file. On 19-Feb-09, at 12:44 PM, Steph Fox wrote: allow_call_time_pass_reference = Off (Issue Warnings) Eric Lee Stewart +1 Switching it off by default in ini-dist and main.c would be good too! http://wiki.php.net/rfc/calltimebyref - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
allow_call_time_pass_reference = Off (Issue Warnings) Eric Lee Stewart +1 Switching it off by default in ini-dist and main.c would be good too! http://wiki.php.net/rfc/calltimebyref - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Vote: allow_call_time_pass_reference value in production INI
Eric Stewart wrote: > We seem to have a split opinion on what the production INI value for > allow_call_time_pass_reference should be. > > As I understand it, this does not enable or disable the ability to pass > references at call time. It only enables or disables PHP's warnings about > this behavior. > > I currently have it set to On because I feel a production server should not > be issuing deprecation type warnings, that is definitely a function for > development servers. But PHP and these INIs belong to us all and I feel the > opinion of the community majority should make this decision. So lets have a > vote. > > allow_call_time_pass_reference = On (Suppress Warnings) > > or > > allow_call_time_pass_reference = Off (Issue Warnings) +1 Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
Eric Stewart a écrit : allow_call_time_pass_reference = Off (Issue Warnings) Hello, +1 too. Olivier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Vote: allow_call_time_pass_reference value in production INI
Hi. On 19.02.2009 6:34 Uhr, Eric Stewart wrote: allow_call_time_pass_reference = Off (Issue Warnings) +1 Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
did you guys see the other patch i posted yesterday? i re-read Johannes' first reply yesterday and saw the bit about a second api for a zend_call_method with a variable number of parameters. so a made a new function then re-implemented zend_call_method based on that. heres the patch (easier to read on pastebin). http://pastebin.com/m4fd58822 im sure it could be tweaked, but i think the main point is using an array rather than va_list to support the varialbe arg list. is this any better than the first one ? thanks, -nathan
[PHP-DEV] Re: Vote: allow_call_time_pass_reference value in production INI
> > allow_call_time_pass_reference = Off (Issue Warnings) > +1 Elizabeth Smith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
On 19-Feb-09, at 12:34 AM, Eric Stewart wrote: allow_call_time_pass_reference = Off (Issue Warnings) +1 Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] [RFC] Better benchmarks for PHP
On Sat, 2009-02-14 at 23:06 +, Nuno Lopes wrote: > Currently PHP's benchmarks are very poor. The PHP interpreter is only timed > against bench.php. Sadly, this doesn't make use of the majority of PHP's IS that something where some GSoC student might help? If yes, please add it to http://wiki.php.net/gsoc/2009 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
2009/2/19 Eric Stewart > > allow_call_time_pass_reference = Off (Issue Warnings) > > +1 -- Mikko Koppanen
Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
hi, On Thu, Feb 19, 2009 at 11:57 AM, Johannes Schlüter wrote: > ps. I'm aware of the fact that we added some specific APIs in special > cases in bug fix releases before, but there's a difference between > adding APIs and breaking the ABI of existing, used, stuff. Exactly. To summarize: x.y.z to x.y.z+1: ABI and API must be 100% compatible x.y.z to x.y+1.z: ABI can be broken (need a recompilation), API must be 100% compatible x.y.z to x+1.y.z: party time ;) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
On Thu, 2009-02-19 at 00:14 +0100, Marcus Boerger wrote: > Stuff like this can imo always be added and whether you do > #if PHP_VERSION_ID >= 50300 > or > #if PHP_VERSION_ID >= 50301 > imo doesn't matter much. It does. Up till now we always tried to keep binary compatibility for "bug fix" releases (z in x.y.z) We have a few vendors of binary extensions (not only Zend ...) which rely on the fact that they can provide one extension build for the whole series - at least as long as their extension aren't reaching too deep into the engine. Oh, and I think this also affects our own Windows builds of PECL stuff... Yes, our development process and release structure might need some updates, but version numbering might be the result from changes there, not the beginning. johannes ps. I'm aware of the fact that we added some specific APIs in special cases in bug fix releases before, but there's a difference between adding APIs and breaking the ABI of existing, used, stuff. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
hi Eric, On Thu, Feb 19, 2009 at 6:34 AM, Eric Stewart wrote: > allow_call_time_pass_reference = Off (Issue Warnings) +1 Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php