I'll post a bug and do this. Shouldn't take long. On Tue, Jun 16, 2009 at 8:23 PM, Maciej Stachowiak <[email protected]> wrote:
> > On Jun 6, 2009, at 8:57 AM, Drew Wilson wrote: > > I can't seem to find any documentation as to what the expected behavior of >> Mutex.lock() is with regard to calling lock() recursively on the same >> thread. >> >> Looking at the pthreads implementation, it appears that when we create the >> mutex we pass null as the attributes, which gives us the default behavior >> (not re-entrant). >> >> The Windows implementation uses EnterCriticalSection which *is* >> re-entrant. >> >> I'm assuming that the pthreads implementation is the correct one (calling >> Mutex.lock() twice on the same mutex on a single thread should deadlock the >> thread) but I wanted to verify this since the implementations seem to vary. >> > > The way I would put it is: Mutex.lock() cannot safely be called by a thread > already holding the lock. I don't think it makes the implementation "wrong" > to allow this to work. But it's true that this could lead developers astray > if they only test on platforms where the implementation of Mutex happens to > be reentrant. Thus, it would be a good idea to document the fact that > reentrancy is not guaranteed, and add ASSERTs to try to check that it is not > relied upon. > > Regards, > Maciej > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
