Re: POE::Component::Server::TCP bug fixes, possibly incompatible
Euh, well, I was meaning option A. But either A or C is good for me. Option B is too awkward as a bad API would stay forever and would bite any new Server::TCP user. Le 21 juillet 2009 12:37, Olivier Mengué a écrit : > > > 2009/7/16 Chris 'BinGOs' Williams > >> Anyways, I see three options: >> >> a). Make the functionality match the documentation; >> >> b). Make the documentation match the functionality; >> >> c). Do what dngor suggests and flatten ClientArgs, forget the socket >>and document as such. >> >> Cheers, >> > > As a POE::Component::Server::TCP user (useful to quickly write tests for > client components), I prefer option C as I complained about 2 months ago : > http://www.mail-archive.com/poe@perl.org/msg04260.html > > Olivier Mengué. >
Re: POE::Component::Server::TCP bug fixes, possibly incompatible
2009/7/16 Chris 'BinGOs' Williams > Anyways, I see three options: > > a). Make the functionality match the documentation; > > b). Make the documentation match the functionality; > > c). Do what dngor suggests and flatten ClientArgs, forget the socket >and document as such. > > Cheers, > As a POE::Component::Server::TCP user (useful to quickly write tests for client components), I prefer option C as I complained about 2 months ago : http://www.mail-archive.com/poe@perl.org/msg04260.html Olivier Mengué.
RE: [QSF] Re: POE+Signals : The final solution
Furthur notes : 1- The signal pipe needs to be rebuilt when you fork off a new process that uses the same kernel. Example would be a pre-forking server. To do this, you need to call $poe_kernel->has_forked. 2- Signals need to be masked while the signal pipe is being rebuilt. We use sigprocmask() for this. This has been tested on cygwin, Mac OS X, Linux and FreeBSD. We don't now how compatible sigprocmask() is with more obscure platforms. -Philip
