RE: IM06 Resolution

Hi John,

> Here is the suggested rewording of section 5.3.3.6 on the g() function
> as per my action item for IM06:

This is a big improvement over the original text! I have only a
couple of comments:

> For purposes of discussions of the g() function in this section,
> "output message" is considered to be one of the following:
> o An arriving message in a SCE-MI message output port that will
> result in a receive callback being called.
> o An input ready notification that will result in an input ready
> callback being called.

While this text is really clear to me, I worry that overloading
the term `output message' is going to cause confusion, especially
when people go back some time later and only read the g()
examples. Perhaps we should define a special term for this, such
as `service request'. We can define service request using your
words:

  A service request is defined to be one of the following:

  o An arriving message in a SCE-MI message output port that will result
    in a receive callback being called.
  o An input ready notification that will result in an input ready
    callback being called.

Then replace `output message' with `service request' in your
proposed text.

What do you think?

Finally, there is still an unresolved question I have with regards
to the pending flag passed to the g() function. Imagine an
implementation that must poll the hardware side to find out if
a port has a message for it. The ServiceLoop() would poll
output ports until it finds a port with a message. It would
then transfer the message and call the Receive() callback on
the message. The question is, is g() supposed to be called
before Receive() or after? If it is called after, pending in
this implementation would always be false since by definition
the ServiceLoop() is unaware of any messages on the hardware
side untill it polls the ports and it always processes messages
it becomes aware of immediately. If g() is called before
the Receive() (or IsReady()) callback then pending will always
be true. Hmm, this leads me to conclude that g() should be
called for each `service request' *after* it has been handled
by its callback and the pending flag is supposed to indicate
if there are any more `service requests' that the ServiceLoop()
is aware of pending to be handled. In my example implementation
pending will always be false, then.

Now, take a look at example 5.3.3.6.3. In this example, if
pending is always false, haveProcessedAtLeast1Message can
never become 1 and g() will always return 1, i.e., the
ServiceLoop() will never exit. Yet the ServiceLoop() can
process any number of `service requests'. Given that the
example is supposed to show how to make ServiceLoop() block
until at *least* 1 message has been processed implying it
may block until more than 1 message has been processed, I
think the example is still valid, although a user might
be surprised at how it works with an implementation like
the one I've described.

Do you agree that an implementation may behave as I described
it (never being aware of more than 1 message)?

Thanks,
Per
Received on Wed Mar 24 07:17:46 2004