misc: module.mk.in msgpairarray.sm state-machine.h

Walt Ligon Wed, 19 Jul 2006 13:24:21 -0700

Actually, that logic would stay pretty much the same - all it reallydoes is change the op code and reset the current_state for the properstate machine based on the request - which is exactly what is needed.

I'm not entirely sure what changes I want to make yet, but yeah, that'sone idea. Right now I'm trying to consolidate and clean up the SM asmuch as I can, with eye towards making opaque to the rest of the codeand ass much as I can do within the server and client with as littleinterface, the better. I want those codes to have a little to do withactually making the SM run as possible, so the more I can make thingswork with fewer exceptions, the better.

It looks to me like I can make what we have there work just fine withconsiderably less gunk. I have yet to dig into the client to see if Ican pull it into line too.


Thanks!

Walt

Phil Carns wrote:

I _think_ that would work- you would just need to take out the speciallogic after the job_testcontext() call in pvfs2-server.c that currentlyprevents unexpected jobs from getting to the point that they triggerstate transitions. Chances are there are some other little details, butI wouldn't expect any show stoppers. The unexpected messages behavelike any other job at that level.

Are you thinking of doing something where you start some generic statemachines that branch off later according to the request type that wasreceived?


-Phil

Walt Ligon wrote:

Phil, in the server, what would you think about creating a SM with onestate that just calls job_bmi_unexpected and mapping an unexpectedrecv to that SM?


Any reason that would mess things up?

Walt

Walt Ligon wrote:

Uh, I'm confused ... "name of the state or eror code" ... do you meanin the jump table, record the name of the state you are jumping toand the state action return code that indicated it?

Yeah, I don't see why not. Ading something to the union is ano-brainer. Ading stuf to the state structure is more complicated.I think once its converted to a set of structures it should be easyenough, but right now it makes things uglier. Maybe we need a -goption on the statecomp (;->) so we can compile it in or out???

OK, I'l file this under todo after the concurent stuf, but don't letmee forget.


Walt

Sam Lang wrote:


Hi Walt,

I like the state machine debug mode that shows the status and errorcode. That makes debugging errors quite a bit easier. This mightbe feature creep, but I guess the next step is to print the name ofthe state or error code instead of the number. Is that easy tochange in the statecomp code? I know all the status codes aredefined in the .sm, but I'm not sure if the parser keeps track ofthem. It would be one more thing to add to the union as well :-).


-sam

Begin forwarded message:

From: CVS commit program <[EMAIL PROTECTED]>
Date: July 16, 2006 4:42:58 PM CDT
To: [EMAIL PROTECTED]

Subject: [Pvfs2-cvs] commit by walt in pvfs2-1/src/common/misc:module.mk.in msgpairarray.sm state-machine.h

Reply-To: [EMAIL PROTECTED]

Update of /projects/cvsroot/pvfs2-1/src/common/misc
In directory parlweb1:/tmp/cvs-serv4099/src/common/misc

Modified Files:
      Tag: WALT3
    module.mk.in msgpairarray.sm state-machine.h
Log Message:
Everything compiles.   Crap!  Now I have to see if it runs!!!


Index: module.mk.in
===================================================================
RCS file: /projects/cvsroot/pvfs2-1/src/common/misc/module.mk.in,v
diff -p -u -r1.26.10.1 -r1.26.10.2
--- module.mk.in    12 Jul 2006 20:17:48 -0000    1.26.10.1
+++ module.mk.in    16 Jul 2006 21:42:57 -0000    1.26.10.2
@@ -11,8 +11,8 @@ LIBSRC += $(DIR)/server-config.c \
       $(DIR)/pint-perf-counter.c \
       $(DIR)/pint-event.c \
       $(DIR)/pint-cached-config.c \
-      $(DIR)/msgpairarray.c \
       $(DIR)/pint-util.c \
+      $(DIR)/msgpairarray.c \
       $(DIR)/realpath.c \
       $(DIR)/tcache.c \
       $(DIR)/state-machine-fns.c
@@ -26,7 +26,6 @@ SERVERSRC += $(DIR)/server-config.c \
          $(DIR)/pint-perf-counter.c \
          $(DIR)/pint-event.c \
          $(DIR)/pint-cached-config.c \
-         $(DIR)/msgpairarray.c \
          $(DIR)/pint-util.c \
          $(DIR)/tcache.c \
           $(DIR)/state-machine-fns.c

Index: msgpairarray.sm
===================================================================
RCS file: /projects/cvsroot/pvfs2-1/src/common/misc/msgpairarray.sm,v
diff -p -u -r1.35 -r1.35.4.1
--- msgpairarray.sm    30 May 2006 22:34:06 -0000    1.35
+++ msgpairarray.sm    16 Jul 2006 21:42:57 -0000    1.35.4.1
@@ -51,16 +51,16 @@ enum
     MSGPAIRS_RETRY = 191
 };

-static int msgpairarray_init(
-    PARENT_SM *sm_p, job_status_s *js_p);
-static int msgpairarray_post(
-    PARENT_SM *sm_p, job_status_s *js_p);
-static int msgpairarray_post_retry(
-    PARENT_SM *sm_p, job_status_s *js_p);
-static int msgpairarray_complete(
-    PARENT_SM *sm_p, job_status_s *js_p);
-static int msgpairarray_completion_fn(
-    PARENT_SM *sm_p, job_status_s *js_p);
+static PINT_sm_action  msgpairarray_init(
+        struct PINT_smcb *smcp, job_status_s *js_p);
+static PINT_sm_action  msgpairarray_post(
+        struct PINT_smcb *smcp, job_status_s *js_p);
+static PINT_sm_action  msgpairarray_post_retry(
+        struct PINT_smcb *smcp, job_status_s *js_p);
+static PINT_sm_action  msgpairarray_complete(
+        struct PINT_smcb *smcp, job_status_s *js_p);
+static PINT_sm_action  msgpairarray_completion_fn(
+        struct PINT_smcb *smcp, job_status_s *js_p);

 %%

@@ -107,14 +107,15 @@ nested machine pvfs2_msgpairarray_sm(

 %%

-static int msgpairarray_init(PARENT_SM *sm_p,
-                             job_status_s *js_p)
+static PINT_sm_action msgpairarray_init(
+        struct PINT_smcb *smcb, job_status_s *js_p)
 {