[Glass] Class var and class inst var caches in libraries

[Paul Baumann via Glass]

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.
On Oct 9, 2016 8:40 PM, "monty via Glass" <glass at lists.gemtalksystems.com>
wrote:

> 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
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20161009/ab9dc011/attachment.html>