Phil Carns wrote:
I think I'm getting voted down here, so I should probably just
shutup, but I don't think in practice we're going to have that many
child state machines that iterating through the list is at all
costly. I'm arguing for simpler mechanisms that fit in with the job
subsystem over something more fancy and possibly slightly better
performing.
Well, as far as the number of SMs goes, I would rather not risk it. I
still hope this is lightweight enough that we could eventually use it in
more places that would generate a lot of children (like a re-architected
sys-io implementation), though I don't know if that will pan out in
practice. I got bitten by a similar assumption in the flow protocol- it
used to track all of its posted operations for testing rather than
relying on someone to notify it of completion. Admittedly the flow
protocol is a more obvious case and I should have known better, but at
the time it seemed reasonable :)
I think that the way that you describe would work fine too, but it
would require a little more active work to check the status of the
array of child SMs and would require more code to keep track of them.
Probably a bit more code yes, but it seems cleaner than keeping
around backpointers and checking for parents. Instead of driving all
state machines from one place, this event notification scheme
essentially replaces the last child state machine with the parent,
which seems like a bit of hack and harder to debug.
I think I'm lost now. What do you mean by replace? The states are
still isolated, jobs trigger the transitions, only one state action gets
executed at a time, there still may be a time gap between completion of
any given child and when the parent picks up processing again, and there
are still frames. I think both approaches will look the same when
running unless I missed something. If Walt puts a longjmp() in there we
can both hit him over the head.
What? What? How else would I do it? ;-)
I think having a pointer to the parent actually improves debugability
(though I'm not sure this approach actually requires it, all you really
need is either a job descriptor or a pointer to a counter). If I have a
state machine that does something bad or gets stuck it would be nice to
be able to work backwards to find out who invoked it, without having to
search for it in a seperate data structure.
I don't mean to keep struggling with this issue- I honestly think that
both approaches are pretty good, and if Walt implements it the way I
think he is going to, then 95% of developers won't notice the difference
anyway. At this point I am mostly hammering away to make sure I am not
missing a larger issue...
-Phil
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
