Date: Sat, 9 Apr 2005 00:04:22 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 536 ************************************************** Friday 08 April 2005 Number 536 ************************************************** Subjects for today 1 Re: Python 2.4.1 EMX port released. : Steven Levine" 2 Re: Python 2.4.1 EMX port released. : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Thu, 07 Apr 2005 18:44:06 -0700 From: "Steven Levine" Subject: Re: Python 2.4.1 EMX port released. In <1DIwtm-1Y6Jiy0 at fwd32.sul.t-online.de>, on 04/06/05 at 12:51 AM, Stefan.Neis at t-online.de said: Hi, >BTW, does anybody know if bigger stack size has any bad influence on >memory consumption? I seem to remember something like the built-in size >just being the upper limit and a thread just using/allocating as much of >it as it needs. Does anyone know something from own experiments or >contra- >dicting documentation? The rules differ for the first thread and other threads. The kernel provides guard page support for the first thread and commits pages as needed as long as the app follows the rules. Other stacks are, as noted, fully committed when the thread is created. When talking about using stack on the first thread what we are really talking about is physical memory and swap space usage. The linear memory address range is used whether or not the memory is committed. FWIW, many ported unix apps would be easier to manage under OS/2 if there was a way to control the thread stack size either with a configuration variable or an enviroment variable. A typical example is apache when running the php module and heavy users of stack such as phpmyadmin. The default thread stack is too small and can not be increased without rebuilding apache or patching the binary. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 2 ==========================** Date: Fri, 08 Apr 2005 11:51:15 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: Python 2.4.1 EMX port released. Steven Levine schrieb: > FWIW, many ported unix apps would be easier to manage > under OS/2 if there was a way to control the thread stack > size either with a configuration variable or an enviroment > variable. Maybe that's something to ask Knut for (which of course will only help programs created with Innotek's libc)... Not sure what you mean by a "configuration variable", but I don't think it would be very difficult to check an environment variable for wanted stack size on thread creation. Maybe something like "if the call passes in '0' as stack size, check the environment variable and set the stack size accordingly, use default value if no environment variable found". Or maybe use '-1' or some other value that's sure to not be currently used to trigger the new behaviour. That way, all programs wanting to support configurable thread stack size would still need to be slightly modified and recompiled, but that shouldn't be a big problem. Of course, thread creation is probably protected by a mutex, so anything increasing the time during which the mutex is locked is probably bad, but I hope that looking up an environment variable is not going to take long enough to cause a real problem. Regards, Stefan