File descriptor limit

[Dan Kegel]

Mike Hearn wrote:
>>18000 is impossible unless the processes' ulimit -n
>>and /proc/sys/fs/file-max are both that or higher, unless
>>I'm seriously confused.
> 
> 
> 18000 was for all the wine processes added together. Normally when I run
> wine, i see in the process list "wine whatever.exe" and "wineserver".
> With this app, I see lots of "wine whatever.exe" processes, so I just
> took the sum of them.

Then I think you may have double-counted some fds.  Each thread
shows up as a process at the moment in Linux.  To avoid double-counting,
take only one of all the tasks with the same memory space.

I think the following line might do the job:

ps augwx | grep wine | grep -v grep | perl -e 'while (<STDIN>) { @x=split(" "); system("ls /proc/$x[1]/fd") if !$seen{$x[4]}++;}' | wc -l

but I haven't tested it thoroughly.

>>I doubt Wine scales well to large numbers of threads or fd's.  Maybe it's
>>time to start seeing where the bottlenecks are...
> 
> 
> I was discussing this with Mike McCormack last night on IRC. He gave me
> some ideas and sent me a couple of patches. As I'm not getting very far
> with this OLE deadlock, I think I'll look at these patches next.

First order of business is a benchmark or two, I think.
For what it's worth, I did a bit of searching, and found a few winsock benchmarky things:

http://www.etestinglabs.com/benchmarks/webbench/webbench.asp
http://www.etestinglabs.com/benchmarks/netbench/home.asp
http://www.sockets.com/samples.htm#WAL

It would be fun to compare webbench scores between the client app
running on Wine, and the client app running on Windows...
dunno if that would stress out the number of fd's in a single
process, but it might.

- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045