-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MARK CALLAGHAN wrote:
> On Mon, Mar 16, 2009 at 1:18 PM, Jay Pipes <[email protected]> wrote:
> I don't particularly care for the existing plugin interface for
> schedulers. After coding up a new scheduler yesterday, I think a number
> of improvements could be made to it.
>
> Here is the existing scheduler plugin interface, as defined in
> drizzled/plugin_scheduling.h:
>
> typedef struct scheduling_st
> {
> uint32_t max_threads;
> uint32_t (*count)(void);
> bool (*init_new_connection_thread)(void);
> bool (*add_connection)(Session *session);
> void (*post_kill_notification)(Session *session);
> bool (*end_thread)(Session *session, bool cache_thread);
> } scheduling_st;
>
> And yes, the above includes ALL of the massive amount of documentation
> for the interface (a whopping total of 0 comments.)
>
> Here are the issues I have with the interface, and some suggestions on
> refactoring it.
>
> 1) The scheduler interface marries OS threads with client connections.
>
> The init_new_connection_thread and end_thread callbacks imply a
> one-to-one relationship between a "connection" (whatever that is...) and
> an OS thread. Furthermore, the max_threads member of the interface
> struct directly suggests a connection to OS threads, when no
> relationship is needed between Sessions and OS threads.
>
> This is not necessary and burdens interface implementors with a
> contrived relationship between Session instances and operating system
> threads when no such relationship is necessary.
>
> Sessions are sessions; a collection of statements being received from a
> connection. OS threads are not directly related to sessions at all. OS
> threads simply supply one processing subsystem for a session's
> execution, nothing more. In fact, there really is no need to have a
> Session instance tied to a specific OS thread at all, though the mysys
> threading subsystem currently marries the two (but that is a technical
> limitation which can be lifted).
>
> 2) The interface does not represent allow interrupts or prioritization
> of Session processing.
>
>> Sessions can sleep after getting a resource (THD::enter_cond in
>> official MySQL, sleep on a row lock in InnoDB). Will you support hooks
>> for waking a scheduled Session in that case?
Yes. I'm working on a design now. It's much easier to think of a
better design when you work on a plugin which needs it. :)
Cheers,
Jay
> A scheduler is simply a struct which provides a method for assigning a
> processor (could be an OS thread, could be a remote process, could be a
> libevent callback, could be Gearman, etc) with a resource which needs
> processing.
>
> Most scheduling interfaces allow for two main things: the ability to
> tell the scheduler how to prioritize incoming resource needing
> processing, and an ability to interrupt processors which are processing
> those resources.
>
> The current scheduling interface allows for neither.
>
> == Proposal ==
>
> I propose to refactor the scheduling_st interface to the following:
>
> typedef struct scheduler_st
> {
> /**
> * Returns number of processors the scheduler uses. For
> * some schedulers, this might be OS threads, for others,
> * the processors could be something different...
> */
> uint32_t (*numProcessors)(void);
> /**
> * Returns number of resources waiting to be processed.
> */
> uint32_t (*numQueuedResources)(void);
> /**
> * Callback called when a resource is pushed
> * to a scheduler for processing.
> */
> bool (*pushResource)(void *resource);
> /**
> * Callback called when a resource is popped
> * from a scheduler processor, either after the
> * processor is done processing the resource or
> * or after, say, an interrupt occurred.
> */
> bool (*popResource)(void *resource);
> } scheduler_st;
>
>
> typedef struct scheduling_resource_st
> {
> int32_t priority;
> void *condition; /* Could be a pthread_cond_t or libevent struct... */
> void *data; /* Could be a Session pointer ... */
> } scheduling_resource_st;
>
> I'd of course much prefer to do the interfaces in C++ to avoid the
> mucky-muck of C's callback mechanisms and use C++ function objects, but
> we have to wait for Monty's work for that... :)
>
> Anyway, thoughts and suggestions appreciated.
>
> -Jay
>>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm/we0ACgkQ2upbWsB4UtGPSgCfU0f14EnLHH7ITTxcNJfLlOxD
e2EAn2UlJUCEj/r3zp1w3ulMqa/f2Rpz
=acSa
-----END PGP SIGNATURE-----
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
