ispawn and icollective

Greg Burns (gdburns@tbag.osc.edu)
Fri, 4 Oct 1996 16:27:35 -0400 (EDT)

I understand that non-blocking collective functions, with the
possible exception of ibarrier, are getting declining support from
the Forum. This would seem to be a major relief for implementors,
because a pending collective request could be a rather complicated beast
to control (a multi-step communication algorithm with multiple concurrent
pt2pt operations), especially for single threaded progression engines.

However, in implementing the MPI-2 dynamic chapter's non-blocking functions,
we have much the same problem, because LAM does collective communication
to create a new communicator (context), an essential part of process
creation. I don't know how many implementors are waist deep in coding
dynamic processes today, as we are, but I thought I should report this
somewhat obscure implementation hurdle, in case others had not considered it.

It is quite likely that we will defer implementation of the non-blocking
spawn functions. [The only one I really want is iaccept.]

-=-
Greg Burns gdburns@osc.edu
Ohio Supercomputer Center http://www.osc.edu/lam.html