[Mono-bugs] [Bug 566057] New: SetMaxThreadCount does not allow you to set a limit lower than its default
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Fri Dec 18 12:35:42 EST 2009
http://bugzilla.novell.com/show_bug.cgi?id=566057
http://bugzilla.novell.com/show_bug.cgi?id=566057#c0
Summary: SetMaxThreadCount does not allow you to set a limit
lower than its default
Classification: Mono
Product: Mono: Class Libraries
Version: 2.4.x
Platform: i686
OS/Version: RHEL 4
Status: NEW
Severity: Critical
Priority: P5 - None
Component: System
AssignedTo: mono-bugs at lists.ximian.com
ReportedBy: dbialac at gmail.com
QAContact: mono-bugs at lists.ximian.com
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us)
AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
According to the MSDN documentation, SetMaxThreadCount should allow me to set
it to a number no lower than the number of CPUs on the system I am on.
Quoting:
You cannot set the number of worker threads or the number of I/O
completion
threads to a number smaller than the number of processors in the
computer.
If the common language runtime is hosted, for example by Internet
Information
Services (IIS) or SQL Server, the host can limit or prevent changes to
the thread pool size.
In my case, I am running a stand-alone process (not hosted by mod_mono) so this
constraint does not apply. With this in mind, I try to set the limit to 16 (2x
per CPU on an 8-cpu virtual server of which I only have 1 CPU) using this code
snippet:
ThreadCount.GetMaxThreads( out worker, out async );
Console.WriteLine( "Worker: " + worker + ", Async: " + async );
ThreadCount.SetMaxThreads( 16, 16 );
int worker;
int async;
ThreadCount.GetMaxThreads( out worker, out async );
Console.WriteLine( "Worker: " + worker + ", Async: " + async );
The output of this is:
Worker: 100, Async: 100
Worker: 100, Async: 100
On a similar server running 2.6.0, the output is:
Worker: 140, Async: 140
Worker: 140, Async: 140
In the mono irc channel we briefly discussed this and I was told, "You don't
want to lower the defaults because of problems that could arise." However,
when virtualizing with openvz, this is not the case. Openvz reports the CPU
hardware that the main system has and mono makes decisions based on this. This
in turn causes the resources that mono wants to use to frequently exceed the
resources actually available to it under the virtualized machine. Though it
can be argued that openvz should report resources /proc according to what it
provides the VM, it can also be argued that mono needs to be flexible enough to
support these kinds of circumstances and further that the function needs to
operate as described in the MSDN .Net documentation.
Reproducible: Always
Steps to Reproduce:
1.Run the code snippet in the 'Details' section
2.
3.
Actual Results:
The MaxThreadCount is unchanged.
Expected Results:
MaxThreadCount should be altered to match the provided parameters so long as it
stays in the confines described in the .Net documentation.
Not relevant to the bug, but I want to say overall kudos with the Mono project.
I really like what you've created here.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs
mailing list