IM06: ServiceLoop() Issues

Hi,

the current rewording proposal for section 5.3.3.6 on the
ServiceLoop() method is as follows (this combines John's
proposal with my proposal introducing the term `service
request', see http://www.eda.org/itc/open/IM06.txt):

  g()
  If g is NULL, the SCE-MI checks for pending input or output message
  transfers to be performed and dispatches them, returning immediately
  afterwards. If g() is non-NULL, the SCE-MI enters a loop of performing
  input or output message transfers but calling g() only for each service
  request.

  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.

  When g() returns 0, control returns from the loop. When g() is called,
  an indication of whether there is at least one output message pending
  is made with the pending flag. The context argument to g() is the
  pointer which is passed as the context argument to ::ServiceLoop().

However, this rewording still has the old misleading language
about the pending flag. When I read this I still read this as
the pending flag is true only when there are service requests
pending to be processed in the future. This is in contrast to
the intent that John and Duaine have explained on several
occassions. They have stated that the pending flag `reflects
the status of the message queues at the time ::ServiceLoop()
was called' (quote from John). Hence, the pending flag is
backwards looking and really reflects whether a service request
was handled by the service loop just before g() is called.

Another thing is that I think the reference to `the time
::ServiceLoop() was called' can be loosened to `the time
at which ::ServiceLoop() determines the status of the
message queues'. This time can be later than the time
of entry but before any service request is processed and
g() is called.

Further, the reference to when ::ServiceLoop() was called
only addresses the first call of g() after ::ServiceLoop()
is called. In the case g() is called more than once in
one invocation of ::ServiceLoop(), the pending flag should
refer to the status of the service request queues at the
time ::ServiceLoop() checks the status between the previous
call of g() and the current call.

There is one point of lingering confusion that I wanted
clarified as well. A strict interpretation of the rewording
above and some comments John made in the past (`The intent
was to call g() (if defined) for each distinct output message
and each distinct input ready callback.') would have that
g() is *only* called when a service request has been
processed. However, I don't think that can be true as the
example in Section 5.3.3.6.2 could not work if that was the
case. g() is also called when no service requests were
processed and pending will *always* be false in this case,
correct?

On the topic of service loop recursion and the g() function
I believe what we need to decide is whether the pending
flag is a global variable or a local one (local to
ServiceLoop()). In the last meeting the consensus was leaning
towards the latter.

Thanks,
Per
Received on Wed Jun 23 09:27:58 2004