On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote:
MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator
used to create the window. associated with win. The group is returned
in group.
Well, it seems OMPI (v1.2 svn) is not returning a duplicate, comparing
the handles with == C
That's fine - please review the standard and let us know.
Meantime, let me explain how the persistent daemon operations currently work
and some of the problems that drove us there (and continue to plague that
mode).
HOW IT CURRENTLY WORKS
First, it is critical to understand the following point: a
On Jul 28, 2007, at 6:27 AM, Jeff Squyres wrote:
On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote:
MPI_WIN_GET_GROUP returns a duplicate of the group of the
communicator
used to create the window. associated with win. The group is returned
in group.
Well, it seems OMPI (v1.2 svn) is not r
On 7/28/07, Brian Barrett wrote:
> In my opinion, we conform to the standard. We reference count the
> group, it's incremented on call to MPI_WIN_GROUP, and you can safely
> call MPI_GROUP_FREE on the group returned from MPI_WIN_GROUP. Groups
> are essentially immutable, so there's no way I can
I tried to free COMM_SELF, and it seems to call the error handler
attached to COMM_WORLD. Is this intended? Should'nt OMPI use the error
handler to COMM_SELF?
As reference, I tried this with MPICH2, and of course the call fails,
but using the error handler in COMM_SELF.
Again, this is a new corne
A simple test trying to free GROUP_EMPTY failed with the following trace.
a.out: ../opal/class/opal_object.h:403: opal_obj_run_destructors:
Assertion `((void *)0) != object->obj_class' failed.
[trantor:19821] *** Process received signal ***
[trantor:19821] Signal: Aborted (6)
[trantor:19821] Signa
