[Mono-list] Couldn't create thread exception for ThreadPool.QueueUserWorkItem

[Gonzalo Paniagua Javier]

On Tue, 2009-07-07 at 17:59 -0300, Arthur Valadares wrote:
> Hi everyone, 
> 
> I need some help with this crash. I looked up on google and only saw
> references to this as an old mono bug, so I'm not sure if this is a bug
> or expected behavior. I'm running an application that open a LOT of
> threads (I see around 1400 on /proc/./status). It uses ThreadPool's
> QueueUserWorkItem quite a lot of times.
> 
> >From what I've read, this method should wait for a thread in ThreadPool
> to return and use it, but it seems at some point it crashes trying to
> create a new thread in ThreadPool. This is the error message I get:
> 
> Unhandled Exception: System.ExecutionEngineException: Couldn't create
> thread
>   at (wrapper managed-to-native)
> object:__icall_wrapper_mono_delegate_begin_invoke (object,intptr)
>   at (wrapper delegate-begin-invoke)
> System.Threading.WaitCallback:begin_invoke_IAsyncResult__this___object_AsyncCallback_object (object,System.AsyncCallback,object)
>   at System.Threading.ThreadPool.QueueUserWorkItem
> (System.Threading.WaitCallback callBack, System.Object state) [0x00000]
> in /home/arthur/mono/mcs/class/corlib/System.Threading/ThreadPool.cs:101 
>   at OpenMetaverse.TexturePipeline.DownloadThread () [0x00000]
> 
> If this is expected behavior, should I increase the number of threads in
> ThreadPool?

Using the threadpool is ok. There's already a configurable limit (see
mono(1)) that is roughly 15 threads per CPU. Unless you have 100cpus, I
don't see the threadpool exhausting the number of threads you're
creating. Do you really need to create all those extra threads?

-Gonzalo