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 Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
