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

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

On 26.11.2016 11:14, Donal K. Fellows wrote:
> [ ... ]
> PROCESS NOTE
>
> While I generally approve of an improved notifier, I'm not sure that a TIP is necessary for doing so. All that scripts or users of Tcl's A API could possibly see would be improvements in efficiency, and those have never been subject to the TIP process in the past. :-)
>
> Still, it's fine to have one for informational purposes. Notifier implementations are an area that is sufficiently tricky that recording the thoughts of the author of the code is vastly valuable.I I do agree now as well that a TIP was/is not necessary; I'll continue updating it
for the purpose of code/design documentation however (current revison is 1.5.)

> IMPLEMENTATION THOUGHTS
>
> When it comes to the implementation, I'm wondering if it would be neater to have alternate files that implement the notifier, one for epoll, one for kqueue, and one for select (for platforms where we can't figure out something better). Then the configure script is (in this area) mainly just selecting which notifier implementation to use. That's how the notifier system is *supposed* to work, and it reduces the amount of #ifdef-fery required, to everyone's relief.
>
> The other real question is whether the configure script is correct. Right now, it selects by the platform's name (whatever 'uname -s' returns) and I'm pretty sure that's a poor choice. For example, I know that there are other platforms that support kqueue, such as OSX (though that prefers its own notifier), so there may be others…
I've pushed a preliminary unix/tcl{Epoll,Kqueue,Select}.c commit for general code
review that updates configure{.ac,} to accept --with-notifier={auto,epoll,kqueue,select},
where the default is `auto.'