[Mpi3-tools] Question about mqs document

[John DelSignore]

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
> 
>  
>