@dom96: > what sort of tasks have you attempted to do using the current GC across > threads...
As follows: 1\. Having to write a wrapper around closures using protect/dispose to guarantee that the environment doesn't get collected on the thread on which they were created when they have been passed to another thread. I suppose that if this was a part of a library somewhere, it would be simpler. 2\. Having to create our own version of seq using shared memory and coming up with our own memory management for them when they need to be passed between threads. Ditto Current =destroy helps with the destruction though. 3\. Having to implement some controller scheduler functionality as globals to "own" some resources so that those resources can be passed through them. I can provide a little example in a few days to show the complexity compared to a language with either full mu;ti-threaded GC or even Swift's RC - I well know some of RC's limitations and Araq has shown me more, but it is still relatively easier to use. The proposed memory management model seems to fix most of the problems to the point that I have begun to emulate part of its functionality within the current destructor system, although the current =sink isn't exactly the same as what =move will be. I'll show how I've done that in the coming example. My work arounds might be instructive on what could be provided to make things easier. Thanks for the offer.
