Event config

[steverhoades]

Add support for EventConfig for the ExtEventLoop. This addresses the issue of epoll not supporting system file descriptors.

Event::add(): Epoll ADD(1) on fd 10 failed.  Old events were 0; read change was 1 (add); write change was 0 (none):

[nrk]

@steverhoades the curious fact is that we discussed this very exact change a few months ago in reactphp/reactphp#234 (it's somewhere in the outdated diffs) but it looks like we ended up forgetting to push it into a subsequent pull request. I'm definitely +1.

@cboden the api change label sounds like something that would cause a BC, or is it just me?

[cboden]

@nrk I've created an "api change" and a "bc break" label to distinguish the two. When I did some curating in the past I was trying to find where we changes things in the API where there weren't BC breaks - this is to make that search easier if anyone needs it again.

[nrk]

@cboden ah OK if there's a separate label to highlight bc breaks then it's fine.

[cboden]

I found the commit @nrk was referring to.

The construct took an EventBase object rather than an EventConfig config object. I'm thinking that might be a better approach. It lets the developer work with (configure) and keep a reference if needed to the EvenBase and gives access to methods like getMethod. Thoughts?

[nrk]

@cboden yes that was the original code but I discussed (not sure if the direct link works for outdated diffs) about using EventConfig instead. I still think it's better to avoid having access to EventBase from external code as it would mean exposing (albeit not directly) too much of the underlying implementation and tinkering with EventBase can lead to all sort of booms and kabooms.

[cboden]

Alrighty 👍

[WyriHaximus]

👍 for this, but how should we go about the Factory? Running into this very issue right now and I prefer not to give users the suggestion to use a specific loop. (And with instructions to avoid this issue with ExtEventLoop.)

[nrk]

@WyriHaximus maybe a sensible default inside the factory class when dealing with ExtEventLoop is to have FEATURE_FDS enabled, but generally speaking I think you most likely don't need/want our default factory anyway as soon as you start caring about specific backend configurations.

[steverhoades]

@WyriHaximus @nrk I would be against \EventConfig::FEATURE_FDS being enabled by default. This causes Event (Libevent) to choose a sub-optimal polling mechanism on linux, poll vs epoll.

[cboden]

@WyriHaximus Not all the events loops share the exact same functionality or configuration. I don't think we should try to have some kind of global configuration thingie. Factory is handy when you're learning or developing but, IMO, if you're launching a project I think you should have one of the extensions loaded and create/configure the corresponding event loop.

@steverhoades Agreed. -1 on FEATURE_FDS by default.

[WyriHaximus]

@nrk I'm not 100% sure that doing that is the most sensible way tbh. Jus threw a thought out there to see what everyone thinks (and I considered as a good plan at that time). As @steverhoades says it has negative downsides (I wasn't aware of) that can't be ignored. And @cboden makes an excellent note about the event loops.

@cboden haven't looked from that perspective at the event loops yet. So you're saying to pick the right loop for the project? Makes sense!

@steverhoades Agreed, also -1 on FEATURE_FDS by default.

[nrk]

@steverhoades you have a point there, then we just need to make it clear enough through documentation how ExtEventLoop behaves and what developers can do.