Hi!
On Mar 16, 2009, at 1:18 PM, Jay Pipes wrote:
And yes, the above includes ALL of the massive amount of documentation
for the interface (a whopping total of 0 comments.)
I am just thankful that MontyW did the structure. You wouldn't believe
how convoluted the old system was. Without that initial structure
work... this would have taken months to do.
Of course, this is a hidden feature in 5.1 :)
1) The scheduler interface marries OS threads with client connections.
Agreed. Plus there is the reuse of the "thread count" lock in both the
kernel and in the plugin. Once we have a safe structure for sessions
(which is what Monty is doing) this would be much easier to deal with.
2) The interface does not represent allow interrupts or prioritization
of Session processing.
Yield points are needed. Maybe... points for kill as well. This is
pretty hard to do though without seeing how the new network protocol
will work.
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... :)
I think you have the right idea... we can pull locks up right now.
What I don't think we can do is figure out yield until Eric is done.
On the C++ note... I would rather turn it into an object. Though... if
we do plugins as a registered "callback" this is really not so much of
an issue... though there would be the benefits of defaults methods for
plugins. For HTON for instance this would be handy (aka... "handler"
would become an object). Though... a full callback system would render
the need for "containers" of specific plugin interfaces
(though...might want to keep it just to make it easier to follow in
the cold). There are also "collections" that really are needed. AKA...
you can't have a scheduler without implementing about ~6 specifc
methods.
But!
For instance there are a number of plugins that could/would want to
share in when a transaction is created/committed/rolled back. Right
now plugins fake up a handlerton to enter into that loop (though I
cleaned this up for replication).
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
