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: [email protected] ReportedBy: [email protected] QAContact: [email protected] 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
