Possible of dealing with SignalEvent

[foalford]

Usually a script using event loop should be able to deal with signals. Instead of using pcntl functions, can we open up the support for SignalEvent?

However as the loop is declared as private, there is no way of implement that by using either timer or tick queue.

Any thought?

[cboden]

That's interesting and something to be further looked in to. I would think we'd alter the EventLoopInterface and support it in each of the implementations (if they're able to). The ExtEventLoop could use SignalEvent and the other implementations could use the pcntl functions (if pcntl is loaded).

[steverhoades]

@cboden EvLoop can also use SignalEvent see example #9 http://us1.php.net/manual/en/ev.examples.php

[clue]

See also #20 for a first starting point.

[jmalloc]

Hey all, I'll probably make an attempt at adding signal support to loop implementations as a matter of necessity. I was considering adding a SignallingLoopInterface with methods to register/unregister signal handlers. This interface would extend LoopInterface, as I'm not sure that all implementations can support signals in a useful way. If it turns out that they can, we could roll the interfaces together. Thoughts @cboden / @clue / anyone?

[mikegioia]

@jmalloc Did you make any progress with that Interface? I'm in a hard place right now needing signal support for a React loop >_<

[cebe]

@mikegioia I am currently using https://github.com/mkraemer/react-pcntl in combination with this patch: #44. Would love to have some feedback in the PR.

[mikegioia]

@cebe I just tested out react-pcntl and applied your patch. It works :D :D However, we're still left with that unsuppressed warning from the stream_select failing. While I haven't written your suggested test case, I'm pretty confident the performance penalty (if there even is one) is negligible for StreamSelectLoop users. I just wonder what the preferred method of dealing with this is. I'd hate to have to fork the repo to add my own @.

Has there been any movement on incorporating your patch?

[cebe]

I'd vote to add the @ on stream_select but I'd also like to hear project maintainers opinion on this matter. @cboden @WyriHaximus what needs to be done to get #44 merged? Could you please take a look?

[jmalloc]

@mikegioia I havent had a chance to address it in any way I'd want to share, just some hacks to get us going at the moment :/

We use an error handler called Asplode, which produces ErrorExceptions from old-style PHP errors. The solution for us was to catch an ErrorException from stream_select and call pcntl_dispatch if the error message describes a signal event. There's probably some overhead involved there, but we use signals in pretty standard ways (to trigger config reloads or to kill gracefully) so it hasn't been a problem.

I'm still keen to attempt a more general solution that doesn't use a timer, but I think it would require the okay to use @ on stream_select as @cebe suggests, and simply call pcntl_dispatch if it's available when the return value is false. It's a bit more complex, but it looks like Icicle.io does something similar.

[mikegioia]

Thanks @jmalloc. I ended up doing something similar with a custom error and exception handler. I'd be curious to see what you did with pcntl_signal_dispatch and why it was needed -- I didn't run into any issues with signal sending once I caught the warning, but I'm unfamiliar with what that function does 😞

[jmalloc]

The handlers registered with pcntl_signal aren't actually invoked when the signal is received, they're only invoked when pcntl_signal_dispatch is called. I think it's somewhat common to register this function as a tick handler, but I haven't tried that.

[cebe]

yes, you register it as tick handler in normal php or in a timer in the eventloop.

[cboden]

Supported now via #44