[Pvfs2-developers] state machine ending

[Phil Carns]

> 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