Collections that use value holders, like Dictionary having Association instances, only have write conflicts on growth or when a value is updated by two gems. A recursion lock on growth (and perhaps removals) can be enough if more than one session is not assigning the same keys. Pre-allocation (using #new:) may remove the need for locks because there would be no resize. A lock on the association can be useful to avoid duplication of effort between sessions that might precede commit failure. KeyValueCollection is object-allocation efficient (faster for some uses) but would have more conflicts on the structures holding values.
Thanks Dale and Paul. I've given up on making my libs #fork-safe on GS because after looking at the source for some of the GS(DevKit) methods I would use, I don't think they can guarantee it.
Instead I'm just focusing on preventing write conflicts. My solution now is forcing explicit initialization of normally lazy-initialized class/class inst vars in a Metacello postLoad on GS. Since the values are mostly immutable, they can be safely persisted, and since the mutable values are all instances of a custom dictionary-like cache class that uses a TransientRecursionLock to guard access to an internal collection wrapped in a TransientValue on GS, these instances can be safely persisted too. In my tests this eliminated all write conflicts, so XMLParser, XMLParserHTML, XMLParserStAX, XPath, and XMLWriter should all be conflict-free during normal use.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
| Free forum by Nabble | Edit this page |