[Mono-devel-list] Mono on a multipocessor

[Sunny]

On Thursday 21 April 2005 09:53, Alex Chudnovsky wrote:
> Sunny wrote:
> >On Thursday 21 April 2005 09:25, Alex Chudnovsky wrote:
> >>I found a solution (hack really) to make .NET programmatically change
> >>maximum limit of threads on Windows,
> >
> >Would you be so kind to share it?
>
> Its here:
> http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=201
>
> Can confirm it works, something that made me feel very happy indeed when
> I run
> into that stupid 25 threads limit in .NET :-)
>
> Considering that async IO uses threads (something I never thought of
> until I run into it)
> 25 limit is way too low and I thought I seen somewhere that Mono by
> default uses far more
> threads than quoted 25. My app SEEMS to be okay, but you never know as
> problem can
> manifest itself in timeouts that should not have happened otherwise.
>
> cheers
>
> Alex

Hi Alex,
thanks for the link, I'll take it a look.

According the limit, and how low it is, that's the way I think it is:
As someone in the list already mentioned, the threads in the ThreadPool are 
good for threads which are short in execution time. As far as creating a new 
thread has it's cost, you do not have to pay this cost for simple thinks. If 
you need a thread which is going to run longer, that it is better to spawn 
your own one.
I haven't gone deep in async socket communication, but what I understand (at 
least in .Net) is, that a thread is only occupied when performs actual work, 
but it is not blocked in waiting state. When a data becomes available, a new 
thread is picked to deal with that event. And actually if there are no free 
threads in the pool, the execution is queued until one is available. And this 
queue is fairly big, although I could not find information how much.
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 
creating a thread when you need it is much reasonable, than keeping resources 
you do not need. For most of the other implementations, the thread pool is 
enough.
As I said, this is only my experience and understanding, and I haven't digged 
too deep in mono implementation, so please feel free to correct me.

Cheers
Sunny