[oi-dev] valgrind and epoll(5) illumos issue

stes@PANDORA.BE stes at telenet.be
Sun Apr 11 06:33:33 UTC 2021


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 ?



More information about the oi-dev mailing list