The Tulip effort [7] grew out of HPC++ work at Indiana University and is now deployed into many Department of Defense and Department of Energy research applications. Tulip supports remote memory copy operations such as Get and Put, remote method invocation, and efficient barrier synchronization.
Tulip uses the handler mechanism to associate computation with incoming messages. However, Tulip does not support more than one message handler in a parallel program. There is exactly one handler function (typically generated by the compiler) that handles all the messages arriving at a node. Tulip is not interrupt driven, so to avoid deadlocks and network congestion, one has to periodically call Poll. Typically, these poll calls are inserted by the compiler which uses Tulip as a back end. This has mandated the inclusion of a barrier primitive in Tulip, since vendor-provided barriers do not call Poll while waiting to synchronize. Apart from HPC++, no other language has been implemented using Tulip. Threads are not integral part of Tulip. (They are however, implemented in HPC++.)