This creates too much burden at startup for mobile apps. Not really an option.

Cannot it then be wrapped under a #if !MOBILE directive?

Rodrigo,

I appreciate that simply uncommenting this might not be acceptable, but we should still endeavor to fix the problem. Not all users of mono are in mobile environments.

Even making a relatively modest (3-5) number of parallel SSL requests before the threadpool has had time to scale out paralyzes the runtime, causing delays that sometimes exceed 5-10s and unexpected latency in many places since the threadpool is so heavily used.

Here's two proposals:

(1) Make this a configuration option, either as an environment variable or otherwise, so users who don't intend to be unwittingly affected by mobile platform optimizations can opt out of this conservative behavior.

(2) Apply the patch, but also reduce MinThreads defaults on mobile platforms to reflect the number of threads that may be safely created quickly at startup. This way, mobile users still get the slow growth by default, but anyone who wants to allow faster on-demand thread creation can opt in using the ThreadPool.SetMinThreads API.

Would you be inclined to accept a patch that implemented either of these?

I think (2) seems like a reasonable approach. @kumpera ?

Hey guys,

This is not only a problem for mobile, it is also a problem for desktops.

Luckily, we already have a --server option (which btw, needs documenting) which can be used to add these behavioral changes. So let us use that existing flag.

Hey @migueldeicaza , I've implemented your suggestion in this alternative pull request: #725 . Thanks

PR #725 was merged, so then I guess this PR can be closed too.