[EMAIL PROTECTED] wrote on Wed, 28 Nov 2007 10:24 -0800:
> Thanks for working on the update, Sam.
> 
> I'm kinda stumped on that statecomp issue too.  I have a couple of random
> ideas to throw out there, but I'm not really thrilled with them either:
> 
> - If we continue on the track of modifying the state machines, it might be
> good to try to get rid of the manual function declarations for this case. 
> For example, maybe add two new directives, a "run_global" and
> "run_external".  The former would be used in create.sm and would be like
> "run" except it wouldn't emit a static modifier on the function
> declaration.  The latter would be used in repair.sm and would be like run
> except it would emit an extern modifier on the function declaration.  Then
> the extra header with function declarations could be dropped from the
> patch.
> 
> - This idea is kind of goofy from an organizational standpoint, but if we
> didn't want to modify statecomp syntax at all, we could just put the
> repair and create state machines in the same .sm file (presumably
> create.sm).  I assume that statecomp already knows to only emit one
> function declaration once even if it is used in two different run
> directives.
> 
> - I haven't looked to see how hard this would be, but maybe these problems
> indicate that it would be better to use nested state machines for this
> purpose rather than reusing state functions.  I know there was a good
> reason for doing it the way the first patch did it (probably the states
> need to be ordered differently enough that the nested machine approach is
> a little tough), but maybe nowadays it is better to go the nested route.

Agree with this last approach.  Nested SMs would be great if they
worked out conceptually.

Or if desperate, put shared functions elsewhere, not under control
of a state machine.  Then each SM can use its own "run my_func"
where each .sm file has

    #include <handy-funcs.h>   /* declares func() */

    static int my_func(SM *sm)
    {
        return func(sm);
    }

Compiler magic should turn that into a noop.

The various rung, run_external, run_global, etc. seem very kludgey
and icky to have to expose to people.  In a perfect world we'd have
a compiler that looks at all the SMs at the same time and gets the
declarations correct, but that's a serious pain and bad idea for
other reasons.

                -- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to