poll vs. epoll

[Shachar Shemesh]

Hi all,

I have a program (a server) that has a very large number of 
synchronization constructs. Even when everything is idle there, 
wineserver is taking 60% of the CPU, raising load average to 2.4. When 
load is applied, response time occasionally jumps from tenths of a 
second to two minutes.

I noticed that in server/fd.c, the wineserver is using "poll" to select 
between file descriptors. The application is going through this code 
over 2000 times a second, with over 380 file descriptors each time. I am 
wondering whether this can be the cause of the slowdown.

One of the possible solutions to this would be to use epoll instead. 
This, of course, would have to be backed by a configure check, as not 
all systems for which wine is intended support epoll. Another, arguably 
better, solution would be to use libevent for this purpose. Libevent has 
the distinct advantage that it automatically chooses the best tool for 
the job (epoll, poll, /dev/poll, or if all else fails, select). However, 
if there is another, independent use of poll, porting the semantics to 
libevent may prove non-trivial.

So what does the forum think?

One last question. What are the "users"? What constructs cause a new 
file descriptor to be allocated in the wineserver?

             Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/