Gordon Henriksen wrote: > Dan Sugalski wrote: > > > > An interpreter *must* lock any shared data structure, > > including PMCs, when accessing them. Otherwise they may > > be in an inconsistent state when being accessed, which will > > lead to data corruption or process crashing, which is > > unacceptable. > > Process crashing unacceptable? Absolutely. Complete agreement. > > Data corruption unacceptable? I disagree. It depends on the > contract put forward by the language in question. Notably, > Perl makes no such guarantees thus far, being as how it > doesn't (any longer) run in a traditional threaded model. > Successfully threaded languages and virtual machines explicitly > make NO such guarantees
Dan's non-negotiable "Thread notes" didn't say the VM's garauntees were non-negotiable ;) Are there differences in the contracts put forth by existing languages which we hope to have parrot implementations? Ironically, wouldn't setting the garauntees against data corruption this high pretty much rule out a pure parrot implementation of an SQL-92 compliant database. SQL-92 defines 4 transaction isolation levels in terms of the phenomena they're meant to allow/avoid: dirty reads, non-repeatable reads, and phantoms. Allowing language level variation in concurrency vs. correctness garuantees? Can of worms? I can already hear Dan, "Nothing to be seen here. -Move along." On the off chance that anyone's interested, here's a critique of the ANSI SQL-92 isolation levels: http://citeseer.nj.nec.com/berenson95critique.html -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
