Hello Serg,
I made the list of things which we covered in this review, which need
action on your side and which are not yet covered by bug reports.
What only matters to me is that they don't get forgotten; so if there
are bug reports it's fine with me, or if they are written on your todo
it's also fine with me. Bug reports have the advantage that the rest of
the team is in the loop.
Here are excerpts from our emails (> > is me).
--------------
A)
> > Make pthread_cond_timedwait()s of wt_thd_timedwait() respond to
> > "KILL"
Right, it's in my todo.
B)
>> + if (ret == WT_DEADLOCK && arg.victim != thd)
>> >> + {
>> >> + DBUG_PRINT("wt", ("killing %s", arg.victim->name));
>> >> + arg.victim->killed=1;
>> >> + pthread_cond_broadcast(&arg.victim->waiting_for->cond);
> > could victim be somewhere in wt_thd_cond_timedwait(), just before
> > one of the two pthread_cond_timedwait(), and thus miss the wake up
> > call?
I'm afraid, yes :(
Looking how to fix it.
C)
>> + diag("deadlock waits up to %7llu us: %5u",
>> >> + wt_wait_table[cnt], wt_wait_stats[cnt]);
> >
> > On Windows the stats above are incorrect, I see all zeroes in
pushbuild:
> > # deadlock waits up to 1 us: 0
> > # deadlock waits up to 2 us: 0
> > # deadlock waits up to 4 us: 0
> > # deadlock waits up to 10 us: 0
> > # deadlock waits up to 22 us: 0
> > # deadlock waits up to 49 us: 0
> > # deadlock waits up to 106 us: 0
> > # deadlock waits up to 232 us: 0
> > # deadlock waits up to 507 us: 0
> > # deadlock waits up to 1105 us: 0
> > # deadlock waits up to 2408 us: 0
> > # deadlock waits up to 5247 us: 0
> > # deadlock waits up to 11433 us: 0
> > # deadlock waits up to 24908 us: 0
> >
> > Could you please look into this?
I will.
