On Mon, Mar 16, 2009 at 1:18 PM, Jay Pipes <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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?
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkm+tC8ACgkQ2upbWsB4UtEsPgCcCg7inhtTRmO/OwF9UFlAGwZs
> kxEAnj4lfBa9Rn8dSgAtBWhLkAIWavym
> =S/i8
> -----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
>
--
Mark Callaghan
[email protected]
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
