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 impl
On Jul 27, 2006, at 10:16 AM, Phil Carns wrote:
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
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 si
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
subsyst
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 don
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 th
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 mor
On Jul 26, 2006, at 5:17 PM, Phil Carns wrote:
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 ke
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
job
I think it would be nice to help prevent programmer error. The same
thing was done with the protocol request structures (see all the
PINT_SERVREQ_*_FILL macros used in the client sms). If you have a
macro, then neglecting to pass in one of the required input fields
results in a compiler error
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 stru
On Jul 26, 2006, at 4:37 PM, Walter B. Ligon III wrote:
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 ha
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
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).
Coul
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
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 S
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 po
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 SM code, now I've
had to add a context id to the smcb and the
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 pa
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 N
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 w
21 matches
Mail list logo
