List:Commits« Previous MessageNext Message »
From:Ingo Strüwing Date:May 6 2009 3:59pm
Subject:Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780
View as plain text  
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
Thread
bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Struewing25 Feb
  • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Davi Arnaut5 May
    • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing5 May
      • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Konstantin Osipov5 May
        • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing6 May
          • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Konstantin Osipov6 May
            • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing6 May
              • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Konstantin Osipov6 May
                • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing7 May
                  • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing12 May
              • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Davi Arnaut6 May
      • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Davi Arnaut6 May
        • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing6 May
          • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Konstantin Osipov6 May
            • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Ingo Strüwing7 May
          • Re: bzr commit into mysql-6.0 branch (ingo.struewing:2779) Bug#37780Davi Arnaut7 May