*sigh* our POSIX::close on $KQueue has always been totally
broken for other reasons, too. For one, $KQueue is a scalar
ref to an integer FD, so we would need use POSIX::close($$KQueue).
POSIX::close($KQueue) (single '$') is closing the wrong thing,
leading to EBADF in the best case.
I'm inclined to only support IO::KQueue on systems with native
kqueue, and not emulation layers like libkqueue; because fully
emulating kqueue is tough w/o kernel support for close-on-fork.
Background:
Native kqueue implies both close-on-exec AND
close-on-fork behavior. No other filetype I know of has
close-on-fork behavior; but it sorta makes sense given
kqueue is keyed exclusively by file descriptor, not the
combination of [file descriptor AND file description]
like epoll is.
So yeah, it can be tough to future proof this in case Linux ever
starts supporting close-on-fork and libkqueue uses it...
Conclusion: ignore kqueue emulation layers like libkqueue and
assume kqueue is always both close-on-exec and close-on-fork;
like it is on FreeBSD.
It's not like Danga::Socket is urgently awaiting another
release given the lack of active maintainer or even ability
to transfer maintainership. So I'll take a look at this
another day...
Anyone: Feel free to plain-text email me or Cc: me on a public
list about epoll/kqueue/poll stuff any time in the future. Just
don't expect me to use proprietary messaging systems or deal
with JavaScript crap on the web.
RT for rt.cpan.org