Hi Gonzalo, thanks for the reply, I know there is a limit, but by reading the MSDN page about QueueUserWorkItem, it was suggested that if you request a thread beyond the ThreadPool limit, it would wait until a thread is freed to give it to the request, and not crash. The exception doens't even come from the ThreadPool,but from the ExecutionEngineException. That's what led me to believe it might not be expected behavior.
It's a callback that keeps firing and it's job is to send an image. Since sending an image can take a while, it stays alive for some time. I already did some work to do a consumer-producer queue, but I would like to avoid it if possible, since my application is being built to stress performance in exactly this point. Thanks, > 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 > > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
