[ofiwg] presentation from today's WG meeting

[Jeff Squyres (jsquyres)]

On Apr 22, 2014, at 11:22 AM, Doug Ledford <dledford at redhat.com> wrote:

> The other thing I want to request is that we plan for making this
> library function either as a single threaded, main loop driven
> application (which the code you've posted seems well suited for), or as
> a threaded, event driven library (which there currently is no definition
> for).  I'm fine if we say that the application must do one or the other
> and not both, or if we have strict rules about how the methods can be
> mixed, but in the event model I specifically imagine that A) the library
> will have its own threads that do certain tasks and B) the library will
> allow the application to register callbacks and instead of the
> application polling the library for received data or send completions,
> we can use those callbacks to notify the application instead (and in
> this case, let's say the application registers a callback for send
> completions, but not for recv completions, then the send path in the
> library would use the callback method while the application would be
> responsible for polling for recv completions).  Exactly which options
> being enabled result in library generated threads would have to be
> explicitly spelled out so that applications that don't want the library
> to generate threads on its own can avoid making it do so.


This is a great idea in principle (it's pretty much the "active messages" idea), but I'll warn that there are many, many dragons here.

The tarpit that this idea leads to is defining exactly what behavior is allowed in a callback.

Case in point: the MPI Forum has argued *for years* (literally) about how to enable callbacks in receives.  It's never happened because of the zillions of corner cases that come up; trying to define them all is a losing game.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/