Davanum Srinivas <[EMAIL PROTECTED]> wrote:
looks like we need a lock for locking access to utfLockRoot :(
I'd think that the whole utfLockRoot thing is broken (you'd need one utfLockRoot per thread since it's perfectly legal for two threads to work on utf8 constants at the same time). However, I think we could just remove the utfLockRoot thing completely, couldn't we? Even if one of the allocations in utf8const.c triggers a garbage collection, the thread holding the utf8Lock will be resumed before the finaliser starts to free unreachable objects (at least with kaffe-gc). This means that we don't have to drop the lock before doing an allocation, which renders utf8LockRoot useless. Or I just overlooked something ...
Regards,
Helmer
The problem is that utf constants are cached in a hash table. If two strings are exactly equals then utf8const does not create a new constant. I don't know if the approach is justified but this justifies the use UTF locking as only one thread at a time should touch the hashtable. The assertion failure in itself is disturbing: it's like the fast lock subsystem is not working properly as it lets at least two threads running concurrently on that part of the code.
Regards, Guilhem.
_______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
