>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Most of what gets flag-checked now will probably do this, yes. >> And why waste the GC data. I suspect that most variables will not be shared. DS> Doesn't matter whether they're shared. Mark & sweep, generational, and DS> refcount garbage collection all need workspace. Typo. I meant sync data. >> Put the sync data into a seperate area and then access the external data. DS> There lies race conditions. (cf 5.6.0's lock issues) For synchronization DS> data to be valid it must be there at creation time. If it needs to be DS> tacked on later you run into race issues with multiple threads trying to DS> init the sync data. How can that be? Data can be inited only by a single thread. If you are discussing the name holding a variable, that's a different issue. But only one thread can create a datum. The addition of sync into each and every SV is an overhead for code not using it. I think it might be possible to handle the locking with a wrapper object. So each shared whatzit has a locking proxy. Each data item that might be shared between threads gets a proxy. So only shared data or what might be accessed through shared data (think tainting. We would be tainting the data with shared-ness.) >> If the sync data is in the SV, I believe there is a race condition between >> the destruction and grabbing a lock. DS> Nope. If the variable is shared, the lock will need to be taken to destroy DS> it. If it's not shared it's not an issue. How can you grab the lock if the data is destroyed? I think the locking structure has to be outside the thing being locked. Then the only single threading would be a global lock on the lock table when adding/removing a lock. <chaim> -- Chaim Frenkel Nonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
