Bug 1036 - Startup delay in thread pool
Summary: Startup delay in thread pool
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: unspecified
Hardware: PC All
: --- normal
Target Milestone: ---
Assignee: Gonzalo Paniagua Javier
Depends on:
Reported: 2011-09-24 19:46 UTC by Brett Ernst
Modified: 2011-09-25 14:28 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Repro showing fast and slow threadpool startup (435 bytes, text/plain)
2011-09-24 19:46 UTC, Brett Ernst

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Brett Ernst 2011-09-24 19:46:57 UTC
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).
Comment 1 Gonzalo Paniagua Javier 2011-09-25 14:28:48 UTC
Fixed in master/a06852a and mono-2-10/35f3c96.