You may want to be able to assign a client session context to a
thread, suspend a client session, reactivate it, etc. Or you may
want to be able to protect user session state from destruction as a
result of a possible thread exit. Or implement asynchronous
operations without thread spinning.
On Tue, May 12, 2009 at 6:19 PM, Masood Mortazavi
> Alex -
> On Tue, May 12, 2009 at 2:07 PM, Alex Esterkin <aesterkin@stripped> wrote:
>> On Tue, May 12, 2009 at 4:36 PM, Brian Aker <brian@stripped> wrote:
>>> On May 12, 2009, at 12:13 PM, Alex Esterkin wrote:
>>>> For all semantic
>>>> purposes, THD=Session.
>>> A Session object can be moved across scheduler objects, there is no 1=1
>>> ratio in Drizzle between Session and Thread.
>> This is exactly the point I am making. In Drizzle, you renamed THD
>> into Session and decoupled threads and sessions - exactly the way it
>> should be. In MySQL, THD is both, a thread and a session state
>> holder, and it should only hold the latter.
> Out of curiosity ... Why would this be inherently good for MySQL?
> Server designs that assign a session to a worker thread are classic.
> However, even in these designs, there may be multiple threads
> attending to a particular session's various functions during its
> lifecycle. In some languages, the base threading libraries offer a
> thread-local object can be assigned or identified with the session
> context for current task being processes by a given thread.
> - m.