[Chicken-hackers] poll(2) with chicken: works - sort of

[Jörg F . Wittenberger]

Hi all,

this is something, which might be worth to consider once the
next Chicken release is out.

Has been cold yesterday in Germany. ;-)

Since poll(2) is usually regarded a better interface/implementation
to rely on up to the point that some people outright reject
select(2) based code without further considerations, I decided
to give it try.

It's kinda convincing for a first shot.

I modified my already modified chicken and added a cond-expand
option to compile either select(2) or poll(2) based i/o.

Now I had a look into how to port this to a native chicken
patch.  Looks like bad luck:

I'm keeping the "struct pollfd" C array in sync with the
list of threads waiting for i/o.  This way I never need
to rebuild it.  However in ##sys#unblock-threads-for-i/o
I need to map from the fd returned from poll(2) to
the list entry...  And here the killer will come in.

Native chicken keeps the list as a linear list.
This would require one ASSOC per fd-test per several
hundred fd's per time slice.

I'm not sure how worth it is, to convert the C code
from select to poll, while not changing this bottleneck.

Now all is not lost.  Just I'll need help with this.

I've been posting about those modifications.  Here a
summary:

* ##sys#fd-list is converted from a linear list
 into a LLRB tree.
* same for timeout queue
* due to history and priorities, the system time
 is still in integer (used ad index into the
 timeout queue, which shares code with the fd list
 implementation to avoid code bloat (the implementation
 is specialized to the key type at macro expansion time))
* the signal handling does never drop signal types.
 (e.g., 101 sudden SIGCHILDs will not cover SIGPIPE)
 it can/will coalesce signals of the same type.
 (Since signals can be lost, signal handlers must
 be written to cope with lost signals anyway.  Coalescing
 happens to be a huge relieve when those 150 child
 processes die with the pull of a network connection.)
* use poll(2) as alternative for select(2)
+ heavily tested (in fact every not I take into my calendar
 wiki, sqlite db or app-source code directory is as part
 of the process replicated on nine hosts.  Five are just ARMs:
 http://ball.askemos.org/DevelopmentNetwork
 this takes less than a second but a huge amount of i/o
 error conditions to cope with.)

Anybody interested to pull this into the official chicken core?

Best Regards

/Jerrry
.....