Sergei Golubchik a écrit :
> Hi, Guilhem!
>
> On Oct 10, Guilhem Bichot wrote:
>> Why don't the two threads wanting the rwlock get this rwlock? The
>> read-locker is the 8th recursive call to deadlock_search(); it wants
>> 38d8b4 (hex address of rwlock), but it already has read-locked those
>> others rwlocks in previous calls of the recursion
>> (waiting_threads.c:419): 38e638, 38d898, 38e638, 38afe8, 38dd38,
>> 38a6d0, 3875c8.
>> This does not include the wanted rwlock.
>> So, I don't know.
>> Maybe it is the deadlock which you feared on certain rwlock
>> implementations? Note that Windows build is using our home-made
>> thr_rwlock.c implementation.
>
> Yes, looks like it's the one.
So what should we do?
If fixing this requires a new rwlock implementation, I suspect this
won't be ready for ~22 Oct (my tentative goal date which would be
reasonable as we have to push in 6.0-main enough days before 6.0.8
cloneoff, and I am on vacation from Oct 27).
Same for failure of maria.test on some Windows machines, I can't
reproduce it.
Last, I am still far from the end of my review.
I wonder - should we push the deadlock handler (merge 5.1-maria into
6.0-maria and then to 6.0-main) but disable it in 6.0-maria? It is not
perfect either as it means the feature will be enabled only at 6.0.9,
which is late. On the other hand, we cannot import test failures in
6.0-main...
--
Mr. Guilhem Bichot <guilhem@stripped>
Sun Microsystems / MySQL, Lead Software Engineer
Bordeaux, France
www.sun.com / www.mysql.com
