* Taking the read half of a reader-writer lock for all pointer mutations
The point here is to block all mutators from mutating the object graph while the collector is traversing it. I can't imagine this being good for performance. This is in addition to the mutex on the PMC. Other threads might be scheduled before GC completes, but don't have to be for GC to proceed.
* OS "pause thread" support
Lots of operating systems (including at least several versions of Mac OS X) don't support this. Maybe parrot can use it when it is available. It's always a dangerous proposition, though; the paused thread might be holding the system's malloc() mutex or something similarly evil. (This evil is why platforms don't always support the construct.) I don't think this is feasible for portability reasons. In this case, other threads would not be scheduled before GC completes.
* Use events
This is my proposition: Have the garbage collector broadcast a "STOP!" event to every other parrot thread, and then wait for them all to rendezvous that they've stopped before GC proceeds. Hold a lock on the thread mutex while doing this, so threads won't start or finish. This has the worst latency characteristics of the three: All other threads would need to be scheduled before GC can begin. Corner cases exist: NCI calls could be long-running and shouldn't block parrot until completion; another thread might try to allocate memory before checking events. Neither is insurmountable.
—
Gordon Henriksen [EMAIL PROTECTED]
