[closer-devel] *root-context* and threads

[Attila Lendvai]

> These options are easier and have less undesirable implications than
> changing the code to protect it against concurrency issues, and they
> may help to localize your problems.
>
> Let me know what you think would work best for you at the moment...


just take your time to find the proper strategy in contextl. the
machines can mostly keep up with the load and this is not a mission
critical app, so if one or two restarts happen it's bearable...

and i think the issue is localized in sbcl (Nikodemus listed what the
things are that need to be protected from concurrent access).


> > but having a protected global cache for the created classes/prototypes
> > may be a good idea nevertheless, because it would probably speed
> > things up in a threaded environment.
>
> I doubt that. A cache is faster when it's small, and keeping the
> caches for layer children local to their parents keeps them small -
> and a small cache justifies the use of a property list, which should
> even make it faster. So I'd like to stick to that, if possible.


i have no numbers, but you should also consider that calling
make-instance on classes, then dispatching on their instances has many
"invisible" performance penalties. huge locks must be held while
defining the class, method caches must be flushed and refilled for new
instances, etc...


> Unless you have performance issues, which I'd like to know about, of
> course. I haven't been able to test ContextL with a large-scale
> application yet...


i'll report back if i have any numbers/thoughts, but for now
performance is not a critical issue.

thanks,

-- 
 attila