Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 487 [details]
Repro showing fast and slow threadpool startup
Using version 2.10.5 - (paste from the mailing list)
I was investigating a small delay that occurs when the first job is submitted to the thread pool. This isn't a big deal for long-running apps, but for small command-line utilities that use one or more async functions, this can create a noticeable pause during startup.
If my theory is correct, it is due to the 500ms throttling in the monitor_thread function in mono/metadata/threadpool.c. The throttle appears to affect the first thread created and therefore the first job queued.
The function start_threadpool_idle_threads appears to work around this by starting some threads up to the minimum, but its invocation on line 1060 was commented out in a March 9 commit with some other changes. Without understanding the reasoning, I'm not sure if it's safe to uncomment the line.
It looks like start_threadpool_idle_threads is also invoked by the SetMinThreads icall, so a workaround is illustrated in the attached repro. Uncomment the marked line to observe the difference in startup delay (e.g. ~12ms vs. ~512ms).
Fixed in master/a06852a and mono-2-10/35f3c96.