One of the assumptions about the MTL’s is that only a given MTL can handle the message
 matching for communications.  This is done to accommodate mpi-like network stack that
 also handle the MPI message matching, which often do not expose their internal data
 structures used for matching.  Open MPI’s point-to-point selection currently forces the
 choice of single pml, and if CM is chosen, only a single MTL.  Under those constraints
 any MTL internal structs can be kept within the scope of the MTL, w/o polluting the global
 name-space.

Rich


On 10/8/07 5:09 PM, "Sajjad Tabib" <stabib@us.ibm.com> wrote:


Hi,

I'm implementing a new MTL component that uses message queues to keep track of posted and unexpected messages. I intended to do this by creating two global queues, one for posted and one for unexpected, until I found that the portals MTL uses a different approach in their queue implemenation. The portal code uses handles to the queues from inside their mca_mtl_portals_module_t to post messages. I couldn't help but wonder, why are the queue handles here? What are the design implications of defining these handle queues in this module struct rather than globally defining them?
I'm an Open MPI newbie and sort of confused on the modular approach taken here and was hoping somebody could point out the pros and the cons of the two approaches. I guess my next question would be: In general, what would you put into a module struct and what wouldn't you?
I will appreciate any pointers that you could give me to help me understand this concept.

Thanks in advance,

Sajjad Tabib

_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel