Phil, that's exactly what I'm thinking about doing. Never planned to
eliminate test() and testsome(), just to simplify them by moving common
code to the state machine just as you suggested. We're on the same
wavelength (scary for you huh?).
I like the state machine debugger, but that will wait until I'm done
with these changes for obvious reasons.
At the moment I've take the approach that all SM must return
SM_ACTION_TERMINATE from the last action function, and then transition
to terminate in the SM. If they do one, but not both it still works but
an error is logged as a warning. Actually, there are good reasons to
use both in the SM implementation.
I think this is workable. If we decide later it suck we can revisit.
Walt
Phil Carns wrote:
So let's assume for the moment we'll take that approach, there is a
related issue with the "cleaning up." In the server, the last state
action is expected to call server_state_machine_complete as you
pointed out and return the return code it provides (which could easily
be changed to be SM_ACTION_TERMINATE). The client has no such call,
but instead uses code in the "test" and "testsome" loops. I'd like to
see the two of them working the same - I could change the client so
there is a similar cleanup function each SM is expected to call, or
alternatively both the client and server could be required to provide
a cleanup callback function that would be called automatically on
terminate.
Of course, if cleanup were called automatically on terminate it might
obviate the need for the SM_ACTION_TERMINATE return code. :-)
Of course this is all pretty much style issues, but it isn't often
someone is up to the elbows in this to go ahead and make such changes.
If you are looking to make the client and server sms more symmetric
regarding how they terminate, it seems like the client sms could just as
easily use a termination function too (whether it is triggered
automatically by the terminate transition, or something run explicitly).
It would just record the status and stick something (either the sm
struct, or some other struct containing just status info) in a client
side completion queue. The client side test functions would still
exist- they would just be simplified into:
- is my op in the completion queue?
- if so return
- if not, then "do work"
- is my op in the completion queue?
- return (either report status or indicate nothing finished)
The "do work" bit would be a subroutine that runs the chunk of code that
is currently duplicated (eek) in PINT_client_state_machine_test and
PINT_client_state_machine_testsome() to push jobs and run the sm engine.
I don't think we can get rid of the test() and testsome() calls on the
client side since we need those to make progress as long as the library
doesn't have a progress thread- but you could definitely pull some of
their work into an sm termination function.
As a side note, a termination function on the client side would also be
a handy place to trigger callback functions if we ever found a need to
go to using threads and a callback based API there.
-Phil
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
