Hi Konstantin,
Konstantin Osipov, 06.05.2009 16:35:
...
Thank you for explaining all these details, and for the vision of a new
interface. However, I think this goes far beyond my current team
assignment. As much as I would like to discuss these things, I need to
concentrate on my team tasks. Fixing the kill handling seems to belong
to your team. I was happy to help with a limited amount of effort. But
this is now out of bounds of what I can justify. Please reassign the
bug. Or agree that I declare it "not a bug: KILL is unreliable by
design", or "won't fix".
> Yes, I don't see how thd->enter_cond() is relevant. Let's take
> event_queue.cc case for example. Could you explain to me how
> checking thd->killed after thd->enter_cond() is relevant using
> this example?
Ok, here is, what I thought could happen:
Thread_1
--------
Event_queue::get_top_for_execution_if_time()
{
...
if (thd->killed)
... // not killed yet
Thread_2
--------
THD:awake()
{
thd_1->killed= KILL_CONNECTION;
...
if (thd_1->mysys_var->current_cond &&
thd_1->mysys_var->current_mutex)
... // not set yet
}
...
cond_wait()
{
enter_cond() // set mysys_var->current_cond && current_mutex
pthread_cond_wait() // hang, wait for next kill
...
}
...
}
If repeating if(thd->killed) after enter_cond(), the KILL would be
detected immediately. If it isn't present at this time either, awake()
would find the mysys_var values after setting it, and broadcast the
condition.
OTOH, I learned from Davi, that there is no guarantee that thread_1 sees
the new value of "killed" immediately after thread_2 sets it. So my idea
may be pointless. Killing won't become reliable anyway.
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
