On 26/04/04, 22:35:28, Kevin Atkinson <[EMAIL PROTECTED]> wrote regarding Re: [aspell-devel] 0.60 hangs at pthread_mutex_lock :
> > Both get_cache_data methods in cache_t.hpp call the mutex lock > > a second time without unlocking. The first lock is on entry and > > the second from copy. This happens when the lock of n is the > > same as that of cache. The mutex will not unlock as the thread > > locked it itself, hence the thread thread blocks on the second > > lock. > Could I have a test cast that will trigger the problem? A case. Pan via gtkspell as mentioned above - fails every time. The key to the problem is the lock of the cache is the same as that of n, n being the object return from the cache by find. I can't tell if this is the error or what is intended. An avoidance tactic is to unlock the mutex explicitly, then it can be unlock after the find and before the copy. Using destructors for the unlock is risky as the unlock will be called at unpredictable times, potentially leading to a hang. _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/aspell-devel
