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

[Jay K]

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

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090929/9955ccdc/attachment-0001.html>