Agreed the ASSERT needn't be Windows only. It's probably better to ASSERT rather than deadlock on platforms without reentrant implementations. :-)
I'll file a bug for this (and might just fix it) in a couple days if there are no more comments. J On Thu, Jun 11, 2009 at 10:39 AM, Dmitry Titov <dim...@chromium.org> wrote: > Then perhaps all implementations could ASSERT in debug on mutex reentrancy > to help discover where differences in behavior are accidentally 'used' (a > stuck thread may sometimes mask some other issues). > > It's not good to have this kind of differences in 'cross-platform' code, > sooner or later it'll cause very cryptic bugs, especially since developers > with Windows background take reentrancy of critical section for granted. > > Dmitry > > On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow <jor...@chromium.org> wrote: > >> I actually had exact the same question (but never got around to asking >> it). >> >> Given that pthreads' implementation is more strict, it'd seem like mutexes >> are not supposed to be reentrant. Maybe the windows version should ASSERT >> on reentrancy when in debug mode? >> >> >> On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson <atwil...@google.com> wrote: >> >>> Any insights here? I'd be happy to add some documentation to Mutex if >>> someone can verify what the intended behavior is... >>> -atw "sending emails to webkit-dev during WWDC is probably futile, I know >>> :)" >>> >>> >>> On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson <atwil...@google.com> 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. >>>> >>>> -atw >>>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
