Subject: RE: SCE-MI Service Loop: Some Questions
From: Bojsen, Per (bojsen@zaiqtech.com)
Date: Thu Jan 29 2004 - 07:47:07 PST
Hi John,
> johnS:
> The intent was to call g() (if defined) for each distinct output
> message and each distinct input ready callback. In other words,
> each time you would call a callback for any reason - be it a
> receive callback or an input ready callback.
Wow, this is not clear at all from the text in Section 5.3.3.6.
This text mentions nothing about input ready callbacks in the
context of the g() callback. Further, the description of g()
states `the SCE-MI enters a loop of performing transfers and then
calling g()'. This sentence could easily be misunderstood to
mean that multiple messages may be transferred between invocations
of g().
> g() was not intended to be called for input messages.
This is not clear at all from the text. One cause of confusion
here is that the first paragraph talks about `messages which are
pending to be sent' which I read as referring to input messages
(because of the use of the verb `send'). Yet, the verb `pending'
is used to (according to the intent you state above) refer to
output messages in the description of g().
> I do agree the wording is vague here and should be clarified.
Ok, I will not harp more on this then :-)
> johnS:
> I agree there was some additional vagueness in the spec. Actually
> the intent here, again, was output messages and input ready
> notifications, and distinctly *not* input messages. In otherwords,
> only things coming from hardware. The flag is 1 if there is at least
> one message pending from hardware when ::ServiceLoop() is called and
> 0 if ::ServiceLoop() is called at a time when the S/W side is aware
> of no messages pending from the hardware.
So does this imply that the hardware side *must* indicate pending
messages to the service loop or is it allowed to do this on
a best effort basis? What I mean is, I can easily envision an
implementation where the service loop will never know of pending
messages on the hardware side of the infrastructure because the
hardware side simply sends what its got. This could be either
due to not implementing a pending indication or, simply, because
the hardware side may only be aware of one message at a time.
In this scenario the pending flag will always be 0.
I am looking at the g() examples. Especially the third example
(Section 5.3.3.6.3). This example seems to assume that g() will
see pending being 1 at some point and uses that to indicate that
at least 1 message has been processed. This example clearly
would not work with the hypothetical implementation above. Does
this then mean that pending should be set to 1 not only when
the hardware is aware of messages it has not yet passed to the
software side but also when the service loop has just received
a message from the hardware side? I guess I am confused about
the exact definition of `pending' and I am asking for some
further clarification.
Note, at Zaiq we have used g() in a very simple manner. In fact,
I think we could change our code to just pass NULL for g(). I
am asking these questions to ensure our SCE-MI implementation is
compliant and to get the text clarified in the next rev. of
the standard.
Thanks,
Per
This archive was generated by hypermail 2b28 : Thu Jan 29 2004 - 07:50:55 PST