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

[Pascal Costanza]

On 6 Nov 2007, at 15:15, Attila Lendvai wrote:

>> Due to a hint at comp.lang.lisp, I am not so sure anymore whether  
>> this
>> is actually a ContextL issue.
>>
>> Are you sure that my caches cause any problems?
>
> this is most probably an sbcl issue, sorry for not being clear enough!
> ("i suspect that the problem happens due to currupting sbcl's internal
> state due to some missing locks in sbcl")

OK, no problem.

> i just got this question when looking for the source of the problem.
>
> but nevertheless i'm not sure how (setf (getf ...)) behaves with
> multiple threads, especially when a new entry is added. after some
> thoughts i think the worst corruption that would happen is duplicate
> entries and deleted entries, so the current situation may not be too
> bad at all.

I'm not sure either, but I have now asked the several vendors. Let's  
see what they say...

I am not changing the code until then - I hope that's ok.

What you could try is to use your own layer metaclasses and return nil  
as second values in adjoin-layer-using-class or remove-layer-using- 
class. This should disable caching.

I could also add a flag to globally disable caching, or even  
conditionally remove the caching code completely (using reader  
conditionals).

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...

> 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.

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...

> but again, i'm talking without
> actually checking the code, so take it with a piece of salt...

OK, I see. But it's good to be aware of these potential issues anyway...


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium