PS - sorry this is so long - its an easy read and I value your advice
- Walt
OK, I"m looking at what happens when a state machine is done. At the
moment I'm using the word "complete" to describewhat happens when a
state ACTION is finished and the state machine is ready for immediate
servicing, so I'm using the word "done" or "finished" or "terminated" to
describe the whole state machine being finished (I invite input on the
best term to use).
Now, currently there are three ways a state machine could indicate its
finished, plus a 4th I'm going to suggest. We need to pick ONE (1) to
use for all of the state machines. Here we go:
1) the client state machines set a field in the state machine struct
op_complete to indicate the state machine is finished. Asside from the
fact that I'm using the term complete for something else, this is a good
candidate.
2) the server state machines run a function that cleans up everything
and then frees the state machine structure. Finally is relies on the
state action returning DEFERRED - since the action did not post a job
and it returned DEFERRED anyway, it will never run again. I don't like
this method because the pointer to the state struct is still accessed
after it is freed. its been working, but if another thread gets in
there we could have a nasty intermittent bug. We certainly need a
cleanup function, and it could indicate finished using the technique
above, but freeing the struct and returning DEFERRED is a bad idea.
3) the state machine language has a keyword that lets you state that the
next state is "terminate" which could be used to finish the state
machine, but right now the code has logic that detects this and prints a
warning that you should NOT use this. I don't know why we created this
method and then made it illegal. Go figure!
4) a fourth way we could consider is adding a return code to the
state_action functions that allow them to signal finished instead of
DEFERRED or COMPLETE as they do now. IOW, using the return value of the
state function rather than the error return code.
We *could* use more than one of these, say #3 and #4 so that you can do
it either way or both. This is analogous to either doing a return or
falling off the end of a function - at least if someone forgets the
explicit form there is a backup automatic form. Of course we might then
end up with some code with an explicit end and some without.
I don't care which of these we use - they all seem about the same to me.
I think if its left up to me I'll use #4 and set it up so #3 works,
but you get a warning in the logs. I'm going to have to change pretty
much all of the SM code anyway, so again, its 6 of one, a half dozen of
the other. If you have any pref, better let me know soon.
Walt
--
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
