Phil, that's exactly what I'm thinking about doing. Never planned to
eliminate test() and testsome(), just to simplify them by moving common
code to the state machine just as you suggested. We're on the same
wavelength (scary for you huh?).
I like the state machine debugger, but that will
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
Hi All,
I noticed that in thread-mgr.c:bmi_thread_function, there is a call
to BMI_test_unexpected if the bmi_unexp_count 0, which only happens
on the server. The value of bmi_unexp_count on the server can be as
high as 50 from the job_bmi_unexp posts in server.c. It looks like
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
Sam Lang wrote:
Hi All,
I noticed that in thread-mgr.c:bmi_thread_function, there is a call to
BMI_test_unexpected if the bmi_unexp_count 0, which only happens on
the server. The value of bmi_unexp_count on the server can be as high
as 50 from the job_bmi_unexp posts in server.c. 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
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
14 matches
Mail list logo
