in following the threads on traversing pmc trees, we seem to have reached a deadlock (pun intended). deadlock detection is a pain as most db designers have found. they don't dare to db level locking for fear of slowdowns. dbs are always modifying rows and tables so fine grained locking is imperative and they live with deadlocks including detecting and clearing them. but how often will we be doing cloning/serializing/DOD scans? i feel they would only be a small fraction of total cpu usage so IMO the simplest solution is a global mutex when doing any scans through the pmcs. this allows for very simple coding and semantics. just lock the mutex before any pmc scan (if there are multiple scan implementations they all lock the same mutex) and do your scan. unlock at completion. pmc scans are all cpu bound so the work has to be done at some point so locking out other scans won't slow down the entire process (unlike db's where many threads will be disk bound and so global locking will slow the whole db down tremendously). yes, the locked out threads will notice a glitch in cpu but GC passes will do the same thing and we accept that.
so i don't see any major downside to a global mutex vs the nastiness of deadlocks and handling them. the mutex means no difficult coding issues and it can handle all the different (i agree with dan and vote for one common scan iterator) possible scan iterators. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org Damian Conway Class in Boston - Sept 2003 -- http://www.stemsystems.com/class
