On Thu, 24 Sep 2009 13:41:29 -0400
"Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:
>
>
> Michael Hunter wrote:
> > On Thu, 24 Sep 2009 12:50:08 -0400
> > "Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:
> >
> > [...]
> >
> >>> ncu_ip.c:1278-1300 What are we trying to fix and why here? We don't
> >>> know that there isn't something in the event stream between what is
> >>> currently being processed and when this will be processed that doesn't
> >>> need to see this ncu up.
> >>>
> >>>
> >> Like Alan said in his comments, if the ncu is already online when DHCP
> >> times out, it means that there is already an address configured for this
> >> NCU. So, we shouldn't be changing to offline*, timed out state.
> >>
> >
> > That still doesn't answer how you know what is in the event stream that
> > hasn't been processed that doesn't take take the ncu down. You are
> > comparing information from the state now to determine how to process an
> > event that will be operating on a possible different state.
> >
> Isn't this true for all calls to nwamd_object_set_state() and
> nwamd_object_set_state_timed() calls? None of these calls care for
> what's already in the event queue. Some of the abnormalities that we
> have seen in the past are related to this. We transition to a state
> without actually caring for what state we are currently in.
s/in/in or will be in/
Correct. That is bad. By mixing things we do immediately with things
that we queue we act on things without haveing processed all the
information.
The problem here is that we could have an ncu down in the event queue
to be processed which would mean that we really want to transition to
off*/TOd. Your change will break in that case.
>
> It appears that all nwamd_*_handle_state_event() should check the
> current state/aux_state before switching to the new state and going
> through the state machine.
If you mean that we should more tightly specify what happens when each
event hits each state (the bifurcation of aux state doesn't reduce the
number of states it just creates more states arranged in a hierarchy) I
agree. There are places where we can ignore aux state and where the
hierarchy helps. There are other places where more of the transitions
need to be specified.
> That will make our state machine a true state
> machine like one would draw on paper. Something like if I am in the
> online state, then I only care about state changes to x,y, and z and the
> rest are ignored.
>
> This is a separate issue though and we have handled some of these with
> if clauses.
Well, in the end it is all an FSM ;) Choosing to be more formal about
our core logic because it is complex in a structured kind of way would
help.
FWIW I don't know how to fix the bug in your code off the top of my
head. You might be able to argue it will never happen or you can
detect when it does/will happen. Or you might be able to stash some
state away that you check in other places. The first seems unlikely.
The second seems hard to get right and ultimately leads us to belts and
braces types of complexity.
mph
>
> Anurag
>
