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

[Olaf Wagner]

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