Re: com php-src: Add SO_REUSEPORT + SO_BROADCAST support via socket stream context option: NEWS UPGRADING ext/ftp/ftp.c main/network.c
main/php_network.h main/streams/xp_socket.c

Sorry about that -- I assumed that since this was a minor option (that should already exist) and not new functionality it was fine. The problem here is that stream_socket_server() binds and listens in the same step. It's currently impossible to assign pre-bind options to a stream socket server for this reason. The existing stream context option approach is well-worn, not a new thing and provides a hook to do things like this right now in a way that maintains BC. You won't hurt my feelings if it needs to be reverted, though I see little difference between adding this now or adding this in 5.6.1. I **do** need this functionality, though. It's not just a spurious addition. Right now I have to resort to all sorts of ridiculous pcntl_fork() hackery to reuse the same port number on the same address for non-blocking servers in multiple processes. Further, these socket options are available across all environments (except Solaris for SO_REUSEPORT) and appropriate #ifdefs are in place just in case. Windows is the only environment that does not benefit from SO_REUSEPORT as its sockets exhibit this feature by default. In my humble opinion the lack of this functionality is a bug. Had I realized other people saw it as a feature I would have submitted a full-blown bug report to go along with it. Sorry again for not asking ahead of time. Revert if you need to revert and I'll just resubmit the same thing in a couple of weeks. On Wed, Aug 6, 2014 at 8:26 AM, Michael Wallner <mike@php.net> wrote: > On 06/08/14 11:59, Julien Pauli wrote: > > On Wed, Aug 6, 2014 at 11:55 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > > > > > > > > > > > On Wed, Aug 6, 2014 at 11:23 AM, Julien Pauli <jpauli@php.net> wrote: > > > > > >> On Wed, Aug 6, 2014 at 11:16 AM, Ferenc Kovacs <tyra3l@gmail.com> > wrote: > > >> > > >>> > > >>> 2014.08.06. 5:17, <rdlowrey@php.net> ezt írta: > > >>>> > > >>>> Commit: a51bf0cadf7862d10b2cc19cae2c991d24d670b1 > > >>>> Author: Daniel Lowrey <rdlowrey@php.net> Mon, 4 Aug 2014 > > >>> 12:41:51 -0400 > > >>>> Parents: 29eb0ea68605e81822e34d5a95443f2c176b2c73 > > >>>> Branches: PHP-5.6 > > >>>> > > >>>> Link: > > >>> > > http://git.php.net/?p=php-src.git;a=commitdiff;h=a51bf0cadf7862d10b2cc19cae2c991d24d670b1 > > >>>> > > >>>> Log: > > >>>> Add SO_REUSEPORT + SO_BROADCAST support via socket stream context > > >>> option > > >>>> > > >>>> Changed paths: > > >>>> M NEWS > > >>>> M UPGRADING > > >>>> M ext/ftp/ftp.c > > >>>> M main/network.c > > >>>> M main/php_network.h > > >>>> M main/streams/xp_socket.c > > >>>> > > >>>> > > >>>> -- > > >>>> PHP CVS Mailing List (http://www.php.net/) > > >>>> To unsubscribe, visit: > > >>>> http://www.php.net/unsub.php > > >>> > > >>> Hi, > > >>> > > >>> we are in feature freeze since beta1, and I don't see any recent > > >>> discussion on this so I would like to revert it from 5.6. > > >>> As far as I can tell this is a self contained feature addition so it > is > > >>> possible to be introduced in a micro version, but I think that an > rfc would > > >>> be warranted. > > >>> > > >> I'm not sure about the need of an RFC. > > >> > > >> This is just about adding options to our network stack, options which > are > > >> welcome and make our network stack richer. > > >> I dont think there is need to discuss and debate, possibly infinitely, > > >> about such additions which are self contained and welcome. > > >> > > >> However, I'm OK to say we should revert from 5.6 branch that we are > > >> trying to make stable. > > >> This could be added to 5.6.1 though, as the inpact is tiny and the > > >> addition is self-contained with no impact elsewhere but in network. > > >> > > >> > > >> Julien.Pauli > > >> > > >> > > > https://wiki.php.net/rfc/releaseprocess > > > "Bugfixes only (with a room for exceptions on a case by case basis and > > > only for small self contained features additions)." > > > I interpret the case-by-case basis as some third-party (eg. not the > > > author) has to approve. > > > Currently we use the rfc process for making decisions, but I guess the > RMs > > > could also be the ones making such decisions. > > > > > > > Exactly. > > For self-contained features, which are not too big (that's the case > here), > > we, as RMs, can make such decisions on behalf of the PHP project. > > We may use such a "right" here, or , if you want to feel more confident, > > you still may throw a mail to intern@ls saying you're gonna merge this > if > > no-one points objections against it ;-) > > > > Julien.Pauli > > > +1 > > -- > Regards, > Mike >