Re: [Chicken-users] Posix threading

[Julian Morrison]

felix winkelmann wrote:

> Locking/making immobile is (AFAICT) not possible - GC is just too
> frequent, and too much interleaved with execution.
>  
What I was thinking is basically a "move/don't move" bit on data, which 
is normally unset but gets set by a special sort of "locking" major GC. 
Locked items are treated as axiomatic reachable and are not moved in 
copying GC. This would then generate a list of locked items to be 
consumed by a corresponding unlock operation.

However, there are other problems with this, so I'm not sure anymore 
it's a workable idea.

Summary of other problems:
- concurrency in shared data (but "it's not our fault if you didn't use 
a readwrite lock"). This includes hidden concurrency caused by eg: closures.
- thread-local (mobile) data becoming part of the state of shared 
(immobile) objects.

The major problem is that GC moves stuff. Perhaps, allow a non-moving GC 
in "thread mode"? (On the heap that is; the stack stuff has to be moved, 
obviously.)

I'm curious, why in particular did you chose a copying GC?

> One way would be (and this isn't very much thought out, yet) to
> allow "worker" threads, each in a separate kernel thread.
Not sure what that means. Why are worker threads less problematic?

One thing that does occur to me is: if you can define a class of "pure" 
functions which are free from side effects, you can provide an 
implicitly threading parallelization construct that can call these, eg 
in the form of a (parralel-map fn lst)

> The distinction
> between stack and heap data would have to be generalized to allow
> multiple stacks. An interesting problem...
Access cross-stack via (hidden, transparent) locatives?