<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
The defaults are still small.<BR>
<BR>
C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3(196): defaultStackSize := 3000;<BR>C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(819):VAR defaultStackSize := 4096;<BR><BR>
I did some experimentation, and I was HOPING to find something like:<BR>
Among all supported platforms, the smallest actual creatable stack is 64K, therefore set our minimum to 64K.<BR>
Or even 16K.<BR>
<BR>
However I didn't find that to be true.<BR>
I think I found I could create stacks as small as 4K, maybe even less.<BR>
<BR>
On the other hand, I'm sure a number of platforms cannot create such small stacks.<BR>
Also I believe the Linux default stack is a whopping 8MB, so you sometimes find code that fails with smaller than that.<BR>
NT defaults tend to either be 1MB or 256K, maybe doubled for 64bit.<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Tue, 29 Sep 2009 10:08:56 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] why Thread.Wait immediately after Thread.Fork?<BR>> <BR>> My guess would be it is the stacksize. The parser will probably<BR>> be a simple LL implementation, and the default size for thread<BR>> stacks was (is?) notorious small in M3.<BR>> <BR>> What are the current defaults?<BR>> <BR>> Olaf<BR>> <BR>> Quoting Jay K <jay.krell@cornell.edu>:<BR>> <BR>> > What is the point of<BR>> ><BR>> > Thread.Wait(Thread.Fork(NEW(ClosureType....));<BR>> ><BR>> > vs. just:<BR>> ><BR>> > NEW(ClosureType....).apply();<BR>> ><BR>> > ?<BR>> ><BR>> > The only reason I can think of is to ensure more stack the <BR>> > ClosureType().apply() than might be present on the current thread.<BR>> ><BR>> > OR maybe an assertion on the author's part that the work <BR>> > could/should be performed without waiting, but he hasn't made it so <BR>> > yet?<BR>> ><BR>> ><BR>> > OR maybe so user can interrupt long running operation with <BR>> > control-c? But that works the same on the original thread, right?<BR>> ><BR>> ><BR>> ><BR>> > OR maybe to stress test the threading library and ensure that thread <BR>> > creation is cheap??<BR>> ><BR>> > These do seem like wasted threads.<BR>> ><BR>> ><BR>> ><BR>> > I have found a few examples. Here is one:<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > m3-ui\formsvbt\src\FormsVBT.m3<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T<BR>> > RAISES {Error} =<BR>> > BEGIN<BR>> > TYPECASE<BR>> > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000,<BR>> > description := description, fv := t,<BR>> > state := state))) OF<BR>> > | TEXT (msg) => RAISE Error (msg)<BR>> > | VBT.T (ch) => RETURN ch<BR>> > ELSE <* ASSERT FALSE *><BR>> > END<BR>> > END Parse;<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > why not:<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T<BR>> > RAISES {Error} =<BR>> > BEGIN<BR>> > TYPECASE<BR>> > NEW (ParseClosure, stackSize := 10000,<BR>> > description := description, fv := t,<BR>> > state := state).apply() OF<BR>> > | TEXT (msg) => RAISE Error (msg)<BR>> > | VBT.T (ch) => RETURN ch<BR>> > ELSE <* ASSERT FALSE *><BR>> > END<BR>> > END Parse;<BR>> ><BR>> ><BR>> ><BR>> ><BR>> ><BR>> > If the point is to ensure enough stack, perhaps a mechanism to <BR>> > report how much stack is left would be reasonable??<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR> </body>
</html>