Hi, Masood,
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.
Regards,
Alex Esterkin
On Tue, May 12, 2009 at 6:19 PM, Masood Mortazavi
<masoodmortazavi@stripped> wrote:
> 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:
>>> Hi!
>>>
>>> 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.
>
> Regards,
> - m.
>
