Re: MySQL Reengineering Project

[Alex Esterkin]

That THD=pthread, is just an implementation detail.   For all semantic
purposes, THD=Session.  It makes no sense for a statement to use
several THDs, especially in a transactional storage engine context.
If you need multithreading, start a thread group under the THD thread.

Similarly, what is the point of running several statements in one THD?
What do you do with results?  In my opinion, it is much cleaner and
better to implement such concurrency at the protocol level, like it is
done in Drizzle, or at the storage engine level.

Regards,

Alex Esterkin

On Tue, May 12, 2009 at 2:54 PM, Sergei Golubchik <serg@stripped> wrote:
> Hi, Brian!
>
> On May 12, Brian Aker wrote:
>> On May 12, 2009, at 11:14 AM, Sergei Golubchik wrote:
>>
>>>  - init() function. Brian added that to pass handlerton down.
>>>    it is ignored by any clean plugin API and should've been done
>>>    differently for storage engines and I_S tables.
>>
>> You should take a look at what Drizzle does as an example:
>>
>> static int compressionudf_plugin_init(PluginRegistry &registry)
>> {
>>   registry.add(&compressudf);
>>   registry.add(&uncompressudf);
>>   registry.add(&uncompressed_lengthudf);
>>   return 0;
>> }
>
> Yes, I've seen that :)
>
>> If I remember correctly the void * was used because before the solution you
>> had devised required that every time we updated a structure we had to
>> update every single plugin (and the original pointer change was done by
>> Tomas Ulin, not myself).
>
> Right, I remember. It was inconvenient, indeed.
>
> The main reason, of course, was that we don't have a clean external
> storage engine API (compare with fulltext parser plugins - no API
> changes in three years).
>
> Still, this could've been fixed differently, without a void* pointer.
>
>>>  - MYSQL_THD is defined as void*, which is fine as it's an opaque
>>>    pointer, plugins are never expected to look inside to cast it
> to
>>>    anything.
>>
>> write_row() in the handler is another example of exposing vs encapsulation
>> (which is fine... if you want to go with C over C++).
>
> write_row() as you know, and as was mentioned in this thread, doesn't
> use its argument at all. We could just as well declare it as a method
> without arguments. At least it would've been less misleading.
>
>>>> Without doing this, and using encapsulation so that a THD can have
>>>> multiple Statements, it will be very difficult to work on any future
>>>> parallelization efforts.
>>>
>>> You mean, a Statement can have multiple THDs, I suppose :)
>>
>> No he means what he is saying. I don't know why you would want a statement
>> shared across multiple THD, but having a THD be able to handle multiple
>> statements means that you can do asynchronous queries within a single
>> connection.
>
> Ah, okay. I see.
>
> I thought that "parallelization", that Jay mentioned, means executing
> parts of a single statement in different threads - which, indeed, may
> need two THDs sharing the same Statement.
>
> Regards / Mit vielen Grüßen,
> Sergei
>
> --
>   __  ___     ___ ____  __
>  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik
> <serg@stripped>
>  / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
> /_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München
> 161028
>       <___/                
>  Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Häring
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals?unsub=1
>
>