I'm sorry, but I have to bring the issue of recursion of 
ServiceLoop() up again. In our discussion at the last meeting we 
did not discuss what happens with the g() function and the 
pending flag in a scenario where ServiceLoop() is recursively 
called. It may be easiest to separate the analysis in two cases: 

  1) Recursion due to Receive() and IsReady() 
  2) Recursion due to g() 

Note, the user is free to use different g() on each (recursive and 
non-recursive) call of g(). 

In case 1 suppose an output message or input-ready notification 
is seen, i.e., the pending flag will become 1. Suppose that 
the Receive() or IsReady() callback that the service request 
triggers will call ServiceLoop() recursively, and that there are 
no more service requests from the hardware side. Now, what should 
pending flag be for the second, recursive invocation of 
ServiceLoop()? Somehow it feels reasonable that it should be 
0/false since that invocation of ServiceLoop() did not actually 
process any requests. Once this invocation returns, the g() 
function called by the outer ServiceLoop() invocation will see 
pending as 1. This has the possibly surprising consequence 
that the inner g() which is called before the outer g() does 
not see any pending messages. 

In case 2, the outer g() is called first, so it sees pending 
1 first. In this case it seems even more reasonable that 
the recursive ServiceLoop should pass pending 0 to the inner 
g(). 

What does the committee think? 

Per 

====================================================================


this should be an easy one.  Is (indirect) ServiceLoop() recursion
allowed?  That is, is it allowed to call ServiceLoop() from a user
callback (g(), IsReady(), Receive())?  The answer to this question
impacts the implementation of ServiceLoop().

Per

====================================================================

We've seen applications that do this so I believe it should
be allowed. However, generally it is not good practice since those
callbacks might have to know how to handle transactions other than
the ones their waiting for - which makes things more complex.

Callbacks should do quick data updates and get out. ::ServiceLoop()
should generally be called from a central dispatcher loop. On
multi-threaded HVLs it should have its own thread.

-- johnS

Argh, that was not the answer I wanted to hear :-)  I assume
these applications are valid and that they would be hard to
write without the recursive call to ServiceLoop()?  Are they
unthreaded applications?

Per