Hi Anh,
1) On issue 1, I think it makes perfect sense to name the parameters in the pointer to function type definition signatures. I think it will help to clarify the interface and make it easier to document. I don't think it changes the interface in any material way.
2) On issue 2, here's what I have in the TotalView "mpi_interface.h" file which is the header file for DLL API:
/* Update log
*
...
* Oct 2 2000 JHC: Add the mqs_get_comm_group function to support
* partial acquisition.
...
*/
/* Extract the group from the current communicator.
* The debugger already knows comm_size, so can allocate a
* suitably sized array for the result. The result is the
* rank in COMM_WORLD of the index'th element in the current
* communicator.
*/
extern int mqs_get_comm_group (mqs_process *, int *);
We also have the implementation of this function for MPICH1 in a file named "dll_mpich.h", as follows:
/***********************************************************************
* Get the group information about the current communicator.
*/
int mqs_get_comm_group (mqs_process *proc, int *group_members)
{
mpich_process_info *p_info = (mpich_process_info *)mqs_get_process_info (proc);
communicator_t *comm = p_info->current_communicator;
if (comm)
{
group_t * g = comm->group;
int i;
for (i=0; i<g->entries; i++)
group_members[i] = g->local_to_global[i];
return mqs_ok;
}
else
return err_no_current_communicator;
} /* mqs_get_comm_group */
We have similar implementations for IBM's MPI DLL on AIX.
So, to answer your questions, the functionality is provided by the DLL, and used by the debugger.
I don't know why it's not implemented in your MPI or in the current MPICH code. FWIW, TotalView considers the implementation of mqs_get_comm_group to be optional, so if the DLL does not define the function, the TotalView MPI MQD DLL wrapper code returns mqs_no_information.
Cheers, John D.
Anh Vo wrote:
> Hi all,
>
>
>
> /_Issue number 1:_/
>
> I�d like to get some feedback on the msq writeup about function
> definition and their description. Please take a look at 6.8.3, for example
>
>
>
> mqs_fetch_data_ft
>
> Function type definition:
>
> typedef int (*mqs_fetch_data_ft) (mqs_process*, mqs_taddr_t, int, void*);
>
>
>
> This is how things are defined in the existing interface. Would it
> actually be more helpful if we do this in the document.
>
>
>
> Function type definition
>
> typedef int (*mqs_fetch_data_ft) (mqs_process* pProcess, mqs_taddr_t
> address, int numBytes, void* buf);
>
>
>
> I.e., give each parameter a name, so that it�s easier to explain each of
> them? Right now my explanation of each of the field is kinda � meh. With
> each of them having a name, we can probably structure them into IN and
> OUT fields (similar to the standard).
>
> Note that this will not change the existing interface, just how we
> present things in the document. The two definitions are completely
> equivalent as far as the compilers and the code generated are concerned
> (please shout if this is not true)
>
>
>
> Last time on the call everyone kinda insisted that the document should
> stay as close to the existing interface as possible so I�d like to get
> an opinion on this.
>
>
>
> /_Issue number 2:_/
>
> I don�t see the definition (implementation) of mqs_get_comm_group in our
> existing code and the existing MPICH code. This should be a
> functionality provided by the DLL, and not the debugger, am I correct?
>
>
>
> --Anh
>
>
>
