This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
If I understand correctly your question, then we don't need any
extension. Each request has a unique ID (from PERUSE perspective).
However, if I remember well this is only half implemented in our
PERUSE layer (i.e. it works only for expected requests). This should
be quite easy to fix, if someone invest few hours into it.
For the context id, a user can always use the c2f function to get the
fortran ID (which for Open MPI is the communicator ID).
On Nov 5, 2007, at 8:01 AM, Terry Dontje wrote:
> Currently in order to do message tracing one either has to rely on
> error prone postprocessing of data or replicating some MPI internals
> in the PMPI layer. It would help Sun's tools group (and I believe U
> Dresden also) if Open MPI would create a couple APIs that exoposed the
> 1. PML Message ids used for a request
> 2. Context id for a specific communicator
> I could see a couple ways of providing this information. Either by
> extending the PERUSE probes or creating actual functions that one
> pass in a request handle or communicator handle to get the appropriate
> data back.
> This is just a thought right now which why this email is not in an RFC
> format. I wanted to get a feel from the community as to the
> interest in
> such APIs and if anyone may have specific issues with us providing
> interfaces. If the responses seems positive I will follow this
> up with an RFC.
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s