-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Another issue I see with the current definition is where the DLL name variables live, which is currently defined to live in the MPI process itself. I was wondering is there was any benefit to allowing (but not requiring) the DLL name variables to live in the MPI starter, rather than the MPI processes. Most implementations currently put MPIR_dll_name[] in the MPI process, but that may require the debugger to read the variable from each MPI process, which creates scalability issues if the debugger wants to load the DLL at a single point in its front-end process. I'd be interested to hear if other feel this is an issue.

Hi John, I'd say it's much of a much-ness really. I'd be happy with supporting that. Allowing the variable to live in the starter is fine - and if it's not there, or not constant in the system, then it would equally be fine in the MPI processes. To scale reading the message queues, you'd already have to have made reading a single variable (ie. the dll name) scale so I don't think scalability of that variable itself is a concern. Regarding the location and reading of the DLL itself, that is a potential concern, ie. is it read in from a global file system at the nodes, or pushed down a tree? Making that scale is something the debugger can do in a way that's appropriate for the system in hand - if need be. Cheers David - -- David Lecomber CTO, Allinea Software Ltd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85Qi8ACgkQHl7D0k2ADlsvTACdGhoBnlyGeS4WGvMuAZPEa7sr MWMAn0lidvjc35iU4itp8qyXg08gPBKX =T3tT -----END PGP SIGNATURE-----