I wonder whether there are many packages using epoll at all.

I happen to see this now because the configure script of squeak-5,
finds /usr/include/sys/epoll.h and enables it.

And it works.  Also if you compile some of the sample epoll servers on the 
internet,
such as:

https://gist.github.com/reterVision/8300781

copy paste to sample-epoll.c and compile it , it works and if you run it under 
valgrind,
you can reproduce the problem easily.

The valgrind source code has a syswrap-linux.c file,
which supports epoll and epoll_ctl as linux specific calls.

So I could copy/paste the code from syswrap-linux.c and use it in 
syswrap-solaris.c.

However does OpenIndiana really have to ship /usr/include/sys/epoll.h ?

The sys/epoll.h header file could be split from SUNWcs package,
and provided in an optional header file package for epoll compatibility.

There are some implications to shipping the header file sys/epoll.h by default.

Also the docs (manpage) itself of illumos is a little bit sceptical or critical 
of epoll.

It writes : 

.  In particular, the Linux epoll facility will -- by design
       -- continue to generate events for closed file descriptors where/when the
       underlying file description remains open.  For example, if one were to
       fork(2) and

https://illumos.org/man/5/epoll

I can add that this seems to be happening in the Smalltalk community,
and that the Smalltalk developer who added epoll support is working on a 
solution for that,
which hits all platforms that use epoll.


So I'm not 100% sure using epoll is a good idea, although it is an interesting 
improvement.


Also is it a decision of OpenIndiana to support epoll or could OpenIndiana just 
remove/split that part from Illumos,
and make it optional ?

_______________________________________________
oi-dev mailing list
[email protected]
https://openindiana.org/mailman/listinfo/oi-dev

Reply via email to