-----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.
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
