Hmm...I had been thinking about a flow implementation that used the new
concurrent state machine code...it sounds like that's a bad idea
because the testing and restarting would take too long to switch
between bmi and trove? We use the post/test model through pvfs2
though, so maybe I
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
Sam Lang wrote:
On Jul 26, 2006, at 6:16 PM, 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
Thanks for the detailed explanation Phil. I hadn't thought about the
context switches that might slow down flow. I was primarily thinking
of something that would be cleaner, and easier to modify and test for
different scenarios. If at some point I get around to playing with a
flow
OK, guys, I have another issue I want input on. When child SMs
terminate they have to notify their parent. The parent has to wait for
all the children to terminate. So I've been thinking to use the job
subsystem for this: the parent would post a job to wait for N children,
and each child
Walter B. Ligon III wrote:
OK, guys, I have another issue I want input on. When child SMs
terminate they have to notify their parent. The parent has to wait for
all the children to terminate. So I've been thinking to use the job
subsystem for this: the parent would post a job to wait for
On Jul 26, 2006, at 12:37 PM, Walter B. Ligon III wrote:
OK, guys, I have another issue I want input on. When child SMs
terminate they have to notify their parent. The parent has to wait
for all the children to terminate. So I've been thinking to use
the job subsystem for this: the
Phil Carns wrote:
Walter B. Ligon III wrote:
OK, guys, I have another issue I want input on. When child SMs
terminate they have to notify their parent. The parent has to wait
for all the children to terminate. So I've been thinking to use the
job subsystem for this: the parent would
On Jul 26, 2006, at 3:41 PM, Walter B. Ligon III wrote:
Yeah, the idea is that the SM code would call the job function.
Depending on the state actions to do it seems like asking for
trouble, all the details that have to be kept up with.
Actually, there are already job structs used by the
Phil, first your questions: The parent will push a frame onto a stack
for each child it is starting. A frame is everything that used to be in
either a s_op or sm_p on the server or client, except for the stuff that
actually runs the SM (now in an smcb). The parent can pass in anything
it
I don't see why the two have to be dependent for this to work. Do you
mean by the parent posting a job, the state machine stepping code would
handling the actual posting? I was assuming that the parent state
action could just call job_concurrent_sm_post (or whatever its called).
Phil Carns wrote:
Phil, first your questions: The parent will push a frame onto a
stack for each child it is starting. A frame is everything that used
to be in either a s_op or sm_p on the server or client, except for the
stuff that actually runs the SM (now in an smcb). The parent can
Sam Lang wrote:
On Jul 26, 2006, at 3:41 PM, Walter B. Ligon III wrote:
Yeah, the idea is that the SM code would call the job function.
Depending on the state actions to do it seems like asking for
trouble, all the details that have to be kept up with.
Actually, there are already job
On Jul 26, 2006, at 5:06 PM, Phil Carns wrote:
I don't see why the two have to be dependent for this to work.
Do you mean by the parent posting a job, the state machine
stepping code would handling the actual posting? I was assuming
that the parent state action could just call
On Jul 26, 2006, at 6:16 PM, 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
15 matches
Mail list logo
