[Mono-devel-list] Mono on a multipocessor

[Alex Chudnovsky]

Sunny wrote:

>On Thursday 21 April 2005 09:53, Alex Chudnovsky wrote:
>
>Yes, this does not help you when dealing with blocking sockets. So maybe it is 
>better to implement your own dynamic size pool to handle this. Or, if these 
>threads stay in blocked state very long, maybe you will find that just 
>
How would this help when I need to use async sockets? I can't say that 
async callbacks stay blocked for a long time (CPU usage is very low and 
they don't do anything heavy), but this limit certainly causes fatal 
problems in .NET. Mono seems to be okay without programmatical change, 
but I wonder if it still has that limit and just queues things, which 
could result in timeouts if number of async sockets is much higher than 
internal limit on number of threads.

I understand desire to have maximum compatibility with actual .NET, but 
surely having higher limits on number of threads is not something that 
would be bad? From what I understand Windows Socket IO uses Completion 
Ports (whatever it is) that are supposedly more efficient, if thats 
indeed the case, then I suppose Mono will need more threads available to 
make up for having less efficient socket IO?

regards,

Alex