Re: [OMPI devel] OSC module change

One day, I should really go remember how all that code I wrote many moons ago works… :). ompi_win_t has to have the group pointer so that the MPI layer can implement MPI_WIN_GET_GROUP. I should have remembered that, rather than suggesting there was work to do. Sorry about that. Brian > On

Re: [OMPI devel] OSC module change

Woo hoo! Thanks for doing that. :-) > On Nov 30, 2017, at 12:43 PM, Clement FOYER wrote: > > Hi devels, > > In fact the communicator's group was already retained in the window > structure. So everything was already in place. I pushed the last > modifications, and

Re: [OMPI devel] OSC module change

Hi devels, In fact the communicator's group was already retained in the window structure. So everything was already in place. I pushed the last modifications, and everything seems ready to be merged in PR#4527. Jeff, the fixup commits are squashed :) Clément On 11/30/2017 12:00 AM,

Re: [OMPI devel] OSC module change

The group is the easiest way to do the mapping from rank in window to ompi_proc_t, so it’s safe to say every window will have one (also, as a way of holding a reference to the ompi_proc_t). So I think it’s safe to say that every OSC module has a group handle somewhere (directly or through the

Re: [OMPI devel] OSC module change

Hi Brian, Even if I see your point, I don't think a user request de free the communicator should necesserily lead to the communicator being deleted, only released from one hold, and available to be disposed by the library. I don't see objection to have the library keep a grab on these

Re: [OMPI devel] OSC module change

The following is perfectly legal: MPI_Comm_dup(some_comm, _comm); MPI_Win_create(…., tmp_comm, ); MPI_Comm_free(tmp_comm); So I don’t think stashing away a communicator is the solution. Is a group sufficient? I think any rational reading of the standard would lead to windows needing to

Re: [OMPI devel] OSC module change

Hi Brian, Let me first start with explaining why we need the communicator. We need to translate local to global rank (aka. rank in your MPI_COMM_WORLD), so that the communication map we provide make sense. The only way today is to go back to a communicator and then basically translate a rank

Re: [OMPI devel] OSC module change

The objection I have to this is that it forces an implementation where every one-sided component is backed by a communicator. While that’s the case today, it’s certainly not required. If you look at Portal 4, for example, there’s one collective call outside of initialization, and that’s a

[OMPI devel] OSC module change

Devels, We would like to change the definition of the OSC module to move the communicator one level up from the different module structures into the base OSC module. The reason for this, as well as a lengthy discussion on other possible solutions can be found in