Sam Lang wrote:
On Jul 24, 2006, at 2:07 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Mon, 24 Jul 2006 14:47 -0400:
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!
I prefer #3 by a large margin over the other options. It's
explicit, not racy, doesn't over-use the return value for a
conceptually different event, and doesn't rely on modifying
parent state. Wonder why it was disabled.
I think terminate ended up being more of a placeholder...we still use
it in quite a few of our state machines, but the last state action is
expected to call server_state_machine_complete which prevents the SM
from transitioning to the 'terminate' state. I've thought of it as an
assert: if you get here you're forgetting something.
It sounds like option 3 is best. My only concern would be using the
state machine definition to define completion makes me forget about
cleaning up in the last action (or actions). I wouldn't mind seeing
option 3 and option 4 being required: check the return code and make
sure the next state is 'terminate'. If one of those fails there's a
bug in the code. I think that might help (at least me) verify that
state actions that are meant to complete need to do cleanup first.
I like that idea. I tend to agree that there is an issue making sure
the state action matches up to the state machine, and that seems like a
reasonable way to do it.
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.
Walt
-sam
Regarding names, STATE_COMPLETE and STATE_MACHINE_TERMINATED seem
like find candidates as you have sort of suggested.
My pocket change.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
--
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
