[M3devel] why Thread.Wait immediately after Thread.Fork?

[Jay K]

The defaults are still small.

 

C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3(196):  defaultStackSize := 3000;
C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(819):VAR defaultStackSize := 4096;


I did some experimentation, and I was HOPING to find something like:

 Among all supported platforms, the smallest actual creatable stack is 64K, therefore set our minimum to 64K.

 Or even 16K.

 

However I didn't find that to be true.

I think I found I could create stacks as small as 4K, maybe even less.

 

On the other hand, I'm sure a number of platforms cannot create such small stacks.

Also I believe the Linux default stack is a whopping 8MB, so you sometimes find code that fails with smaller than that.

NT defaults tend to either be 1MB or 256K, maybe doubled for 64bit.

 

 - Jay

 
> Date: Tue, 29 Sep 2009 10:08:56 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] why Thread.Wait immediately after Thread.Fork?
> 
> My guess would be it is the stacksize. The parser will probably
> be a simple LL implementation, and the default size for thread
> stacks was (is?) notorious small in M3.
> 
> What are the current defaults?
> 
> Olaf
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > What is the point of
> >
> > Thread.Wait(Thread.Fork(NEW(ClosureType....));
> >
> > vs. just:
> >
> > NEW(ClosureType....).apply();
> >
> > ?
> >
> > The only reason I can think of is to ensure more stack the 
> > ClosureType().apply() than might be present on the current thread.
> >
> > OR maybe an assertion on the author's part that the work 
> > could/should be performed without waiting, but he hasn't made it so 
> > yet?
> >
> >
> > OR maybe so user can interrupt long running operation with 
> > control-c? But that works the same on the original thread, right?
> >
> >
> >
> > OR maybe to stress test the threading library and ensure that thread 
> > creation is cheap??
> >
> > These do seem like wasted threads.
> >
> >
> >
> > I have found a few examples. Here is one:
> >
> >
> >
> >
> > m3-ui\formsvbt\src\FormsVBT.m3
> >
> >
> >
> >
> > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T
> > RAISES {Error} =
> > BEGIN
> > TYPECASE
> > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000,
> > description := description, fv := t,
> > state := state))) OF
> > | TEXT (msg) => RAISE Error (msg)
> > | VBT.T (ch) => RETURN ch
> > ELSE <* ASSERT FALSE *>
> > END
> > END Parse;
> >
> >
> >
> >
> > why not:
> >
> >
> >
> >
> > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T
> > RAISES {Error} =
> > BEGIN
> > TYPECASE
> > NEW (ParseClosure, stackSize := 10000,
> > description := description, fv := t,
> > state := state).apply() OF
> > | TEXT (msg) => RAISE Error (msg)
> > | VBT.T (ch) => RETURN ch
> > ELSE <* ASSERT FALSE *>
> > END
> > END Parse;
> >
> >
> >
> >
> >
> > If the point is to ensure enough stack, perhaps a mechanism to 
> > report how much stack is left would be reasonable??
> >
> >
> >
> >
> > - Jay
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090929/bf90282b/attachment-0002.html>