Subject: Nonblocking functions and handlers.

From: Adam Greenberg <[email-masked]>
Date: Tue, 24 Nov 92 22:28:41 EST

I would like to float a few questions about what we mean by the modifier
nonblocking it is applied to the MPI specification.

Nonblocking Send:  

This is the curious one.  Does is mean:

  a) The user may alter the contents of the buffer once the send function
     returns control?

     or

  b) The user must check the status of the send operation to determine when it
     is safe to alter the contents of the buffer?

Nonblocking receive:

This seems pretty clear.  The user must inquire of the system to determine if
the user specified buffer contains the desired message.

In either case, it may be desirable to specify an action that is to occur once
the operation is complete.  Consider adding two arguments to the send and
receive functions:

MPI_<send,recv>_n( int <dest,src>, int tag, void * buffer, int len,
                   void (* handler)(), void * arg )

Here, handler is a pointer to a function which accepts two arguments:
  handler( int msg_id, <type> * arg )

Upon completion of the send or receive operation, the handler function is
invoked and provided with the id of the message operation just completed and
the argument address provided by the user.

I raise the issue of handlers because we have ben asked repeatedly to provide
such fuctionality.

Thoughts?
moose

---

From: [email-masked] (Peter Rigsbee)
Date: Wed, 25 Nov 92 9:12:49 CST

> the argument address provided by the user.

I've never really liked this approach.  I think it adds complexity without
really adding much value.  A couple of issues:

	- first, like most signal handling, this kind of capability tends
	  to be more oriented towards C programs and away from Fortran
	  programs (note that your prototype for "handler" is such that 
	  it could not be programmed in Fortran)

	- second, even if you have a signal handler, the mainline of the
	  application must still poll something to see if the operation has 
	  completed; the difference is that the "something" if often a
	  local variable rather than the messaging system.  But the logic
	  in the program is similar and it is likely that the number and
	  decision of where to poll is driven by the algorithm.

	- third, do all architectures provide the user-level interrupts
	  needed to implement this?  If one doesn't, adding this 
	  functionality may simply not be possible.

IMO, this seems like something that isn't desirable as a part of MPI1.

	- Peter Rigsbee

---

From: [email-masked] (William Gropp)
Date: Wed, 25 Nov 92 09:28:43 CST

I'd love to see a standard implementation that invoked a routine on receipt,
particularly if that routine was not restricted in any way (for example,
restricted to not using any MPI calls).  Unfortunately, doing this right
makes demands on the underlying OS that may be more than some vendors
are willing to commit to.  We need to be careful here.  Note that
Unix does not provide this functionality to users, though VMS has for a long 
time.

(Warning: radical position that I'm not sure even I hold follows:)
An interesting issue is whether we should defer all nonblocking communications
to a thread-based execution model.

Bill Gropp