Re: Back & Forth - Co-routines

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

: x ( -- xt )
  here 0 , [{: addr :}d addr @ 1+ dup addr ! ;] ;

Nice ;).

: x ( -- xt )
  0 <{: w^ n :}d n ;> drop [{: n :}d n @ 1+ dup n ! ;] ;

Why do you use <{: ... :}> instead of something like [{: ... :} ... ;]w  ?

another suffix could be added to put closure locals in the gc'd heap.

Yes.  There is :}xt for passing an xt that performs the allocation.
See <https://gforth.org/manual/Closures.html> for all of these topics.

Ah nice, I did see the mention of :}xt in the docs, but didn't connect
that with garbage collection.  It seems worth a mention.  I saw the
paper when it came out but should look at it again.  I would say having
to pass the allocator to the xt is a bit messy though there is probably
a simple way to wrap it automatically.

Also in a threaded program I guess it would have to stop any threads
that shared a GC'd heap during collection of that heap.

>
That's a tough one.  My current thinking is along the lines of a
per-thread allocator and garbage-collector, with no heap-allocated
data passed between threads.  Then thread-unaware GCs are good enough.

Ergh, that adds a new layer of discipline required of the program,
avoiding passing gc'd data between threads.  For example, the :}h1
allocator could leak memory you pass the xt to another thread and the
receiver never calls it.  So you might prefer to use the gc allocator,
but then the message passing scheme breaks the heap-per-thread
invariant.

Erlang handles this by serializing and copying the closure from the
sender's heap to the receiver's during message passing.  Maybe gforth
could get a library function that does something similar.  Python and
GHC don't attempt separate heaps per thread, and it's common in them to
pass shared heap data between threads using message queues.  The main
convention you have to follow in Python is that any mutating objects
must be owned by a single thread and not accessed by any others.
Attempting to e.g. protect them with locks turns into a big mess.

OTOH, if Gforth is going to use a copying approach, maybe it should go
the full Erlang route and use multiple processes instead of Posix threads.