Scott Lamb wrote:
>>> * What's your use case for ev_loop_new() and ev_loop_default()'s bitmask
>>> of allowed implementations?
>> libevents unconditional use of getenv raised concerns with me and
>> apperently some users on this list, too, so this is one way to disable
>> this (EVMETHOD_ANY instead of EVMETHOD_ALL). Also, I am sure some apps
>> want control over the allowed event loops, e.g. to rule out select becasue
>> it is known to be not wrokign for them.
> Ahh, I'd have to agree that getenv() seems sketchy. But with the
> interface you've supplied, you can't simply blacklist select() without

Hmm. I was going to check this out more and forgot before sending the email.

Realistically, I think unit tests and bug reports/workarounds are about
the only reason to blacklist specific event dispatchers. select() sucks,
but well, that's why it's at the bottom of the list, right?

If you are really concerned about syscall overhead (you mentioned it in
another context, though I don't think it should be a major concern), you
might want to prefer poll() to epoll() or kqueue() if you're going to
use a loop a couple times on a small number of fds then throw it away.
But that's a situation where you'd want a little more coarseness: low
startup overhead methods vs. low per-socket overhead ones. Resorting to
naming specific event mechanisms seems undesirable in terms of older
programs taking advantage of newer event facilities.
Libevent-users mailing list

Reply via email to