When using LIBEV, KQUEUE isn't chosen

[rneswold]

I run LWT on a NetBSD system. I recently submitted a patch [/pull/79] allowing the configuration to properly recognize that libev is present on a system using PKGSRC. Now that I'm able to properly install and use it, it appears that KQUEUEs (NetBSD's most efficient handle multiplexer) aren't being used. I also don't see any way for me to insist that LWT use KQUEUEs with libev.

When I installed libev, its config detection found kqueue.h, et al. LWT's config now finds libev. But when I run my program, I see (via top) that it's blocking via select, not kqueue like it should be.

[ghost]

There is this in the libev documentation:

kqueue is buggy

The kqueue syscall is broken in all known versions - most versions support only sockets, many support pipes.

Libev tries to work around this by not using kqueue by default on this rotten platform, but of course you can still ask for it when creating a loop - embedding a socket-only kqueue loop into a select-based one is probably going to work well.

Also it seems that setting the environment variable LIBEV_FLAGS to 8 should force libev to choose the kqueue backend.

[rneswold]

Thanks for finding the environment flag! I didn't see it mentioned when I read the documentation and header files.

(...after testing...)

LIBEV_FLAGS didn't work. The documentation says it will enable and use kqueue for NetBSD, since it's the only platform that has a non-buggy version. But it's still not getting used. I'll investigate the libev end of this, since that seems to be where the problem is.

[yallop]

#269 adds a way to select the kqueue libev backend.