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
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
