Re: [TCLCORE] TIP #458: Add Support for epoll() and kqueue() in the Notifier

[Lucio A. I. A. <l.i...@gm...>]

> Is there a good reason for Tcl to support multiple native
> event handling interfaces rather than moving towards an
> abstraction library? A good candidate is libuv [1],
> which is the hottest "successor" of libev due to its
> windows support (IOCP) ... and probably due to its
> usage in nde.js. libuv uses kqueue, (e)poll, IOCP,
> eventfd, etc. where possible; .... and it is based on
> a MIT-style license.
> [ ... ]
> By using such a library, there is a hope to reduce the number
> of separate source code variants and ifdefs in the Tcl code base
> and reduce maintenance costs.
Wishful thinking. First of of all, the epoll(2) source module has 674 SLOC
and the kqueue(2) source module has 691 SLOC. If you add the 403 SLOC from
tclUnixNotfy.c to that you barely get 1k SLOC. I don't think libuv can beat
that, especially considering that asynchronous I/O and IOCPs on Windows on
Solaris require quite a bit more than just the notifier backend/implementation.
Secondly, there is no #ifdef jungle in tcl{Epoll,Kqueue}Notfy.c and the amount
of `extra' notifier source modules is two/three (epoll(7), kqueue(2), kqueue(2)
on Mac OS X.)
Thirdly, `hottest' does not mean `best', especially these days; nor does `node.js.'

> Addressing the shortcomings of select() is certainly worthwhile,
> but the question is whether we want to test all these variants
> on all platforms, with sometimes broken implementations
All? You mean FreeBSD, DragonFlyBSD, NetBSD, OpenBSD, Mac OS X, and Linux.
I'm open for suggestions.