[gnet] performance of poll() in single-threaded apps

[Tim Muller <tpm101 gmx net>]

Hi,

I'm writing on a server based on gnetlib/glib for linux that needs to handle 
a large number (500-5000) of not necessarily very busy connections. The 
"churn" rate of these connections is fairly low (i.e. maybe 1% are 
disconnected and/or newly established in any 1-minute interval or so).

The application should be single-threaded, and will use GServer* for the door 
port and then work with the GConn* callback as these connections are accepted.

As far as I know glib, and thus gnet, uses poll() and/or select() in order to 
find out whether events have occured on a set of filedescriptors, rather than 
signal-driven asynchroneous I/O notification possible from linux 2.2 kernels 
onwards (which would be far more effective, because a signal is sent to the 
process whenever an event occurs and the signal handler receives a structure 
that contains the file descriptor, so that we'd know which fd is affected 
without having to check every single one of them).


The question is now: Has anyone any experience or thoughts as to how much 
such a single-threaded app will be slowed down by the large number of 
polls() necessary? As the server itself will need some serious CPU power to 
serve requests, it would be rather unfortunate if I found out that it spends 
50% of its time just poll'ing  :-)


Any thoughts on this matter highly welcome and appreciated (especially as I'm 
not really very deep into the matter).

Many thanks in advance.

Cheers
-Tim

PS: These are some pages are found that made me think about this issue, even 
if I don't _really_ understand half of it :-)
http://www.kegel.com/c10k.html
http://www.atnf.csiro.au/people/rgooch/linux/docs/io-events.html