[Pvfs2-developers] state machine ending

[Walter B. Ligon III]

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