Re: statemachine flaws/weaknesses

[Ladislav Michl]

On Tue, Feb 25, 2003 at 09:55:48AM +0000, Chris Kemp wrote:
> On 2003.02.25 09:10 Pawel Kot wrote:
> > >>> address@hidden 25 February 2003 00:22:58 >>>
> > > IMHO moving the call of the sm_incoming_acknowledge() function into
> > the
> > > fb3110_message_send() or fb3110_tx_frame_send() can solve this
> > problem.
> > 
> > But this is ugly. Maybe just add another argument for the sm_block()
> > functions and use it as the bitmap field? Eg:
> > 
> > #define GN_SM_RETRY_WHEN_NO_ACK 1
> > #define GN_SM_RETRY_WHEN_NO_ANSWER 2
> > 
> > caller:
> > sm_block(GN_SM_RETRY_WHEN_NO_ACK | GN_SM_RETRY_WHEN_NO_ANSWER,
> >         waitfor, timeout, data, state)
> > or
> > sm_block(GN_SM_RETRY_WHEN_NO_ANSWER,
> >         waitfor, timeout, data, state)
> > or
> > sm_block(0,
> >         waitfor, timeout, data, state)
> > 
> > And the optional loops in sm_block() or __sm_block(). What about it?
> 
> Rather than add another argument, are these parameters not basically
> phone/link dependent (ie they don't change often or at all per run time)? 
> If so they can go somewhere in the 'state' system and be setup by the
> phone/link drivers.

yeah, i like it. passing such kind of values in the 'state' system is so
nice idea that i wonder why is wasn't invented earlier. (because such kind
of solution is difficult to invent? :)

        ladis