From: no.email@nospam.invalid   
      
   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  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.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)