- Mpi3-bwcompat - mailman3.cels.anl.gov

Re: [Mpi3-bwcompat] Plan for MPI_Count
by unknown＠example.com 09 Mar '11

09 Mar '11

It contains (or I think it does) the full content of any chapter that was changed. Do you want a copy with just the pages that changed? Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 09, 2011 10:47 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: >>> - Dave will send a final PDF to the bwcompat group to review early next week > > I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? > > Thanks, > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Plan for MPI_Count
by unknown＠example.com 09 Mar '11

09 Mar '11

It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: >>> - Dave will send a final PDF to the bwcompat group to review early next week > > I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? > > Thanks, > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

On Mar 8, 2011, at 4:56 PM CST, Fab Tillier wrote: > In your example, what thread calls MPI_GREQUEST_COMPLETE? What happens to the thread that is blocked in MPI_WAITANY when the signal comes in? It would be the same thread that is blocked in MPI_WAITANY, but it has just been interrupted by the signal. It would require a signal-safe MPI library that permitted MPI calls within signal handlers, which is recommended by the standard but not strictly required. See MPI-2.2, page 24, lines 24-34: ----8<---- MPI does not specify the interaction of processes with signals and does not require that MPI be signal safe. The implementation may reserve some signals for its own use. It is required that the implementation document which signals it uses, and it is strongly recommended that it not use SIGALRM, SIGFPE, or SIGIO. Implementations may also prohibit the use of MPI calls from within signal handlers. In multithreaded environments, users can avoid conflicts between signals and the MPI library by catching signals only on threads that do not execute MPI calls. High quality single-threaded implementations will be signal safe: an MPI call suspended by a signal will resume and complete normally after the signal is handled. ----8<---- -Dave > Rajeev Thakur wrote on Tue, 8 Mar 2011 at 14:31:58 > >> Generalized requests could still be used in single threaded mode with >> signals (SIGALRM) I think.

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

Hi Rajeev, In your example, what thread calls MPI_GREQUEST_COMPLETE? What happens to the thread that is blocked in MPI_WAITANY when the signal comes in? Thanks, -Fab Rajeev Thakur wrote on Tue, 8 Mar 2011 at 14:31:58 > Generalized requests could still be used in single threaded mode with > signals (SIGALRM) I think. > > Rajeev > > > On Mar 8, 2011, at 1:09 PM, Dave Goodell wrote: > >> Sure, that sounds like a reasonable justification. I just wanted to make > sure that you actually had that before you went forward to the Forum, since > that's one of the things that I always ask when someone brings a new > proposal to the whole group and it wasn't present on your original slides. >> >> -Dave >> >> On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: >> >>> I had to go back and read about generalized requests to remind myself >>> how they worked... >>> >>> But now I agree with Fab. They won't work as timers except in >>> THREAD_MULTIPLE + multiple threads scenarios. >>> >>> So I think that the timers-as-requests idea still stands... >>> >>> >>> On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: >>> >>>> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>>>> >>>>> Dave's point about generalized requests is a good one, though -- I >>>>> need to go think about that and convince myself that what we're >>>>> talking about isn't syntactic sugar and/or why it's better to be in >>>>> the MPI implementation. >>>> >>>> In a MPI_THREAD_SERIALIZED implementation, you can't use call > MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. > Depending on generalized requests would require MPI_THREAD_MULTIPLE > support for this functionality. >>>> >>>> Note that for some implementations, making > MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no > MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of > noting that some things are thread safe while others are not - it's either all > or nothing. >>>> >>>> -Fab >>>> >>>> _______________________________________________ >>>> Mpi3-bwcompat mailing list >>>> Mpi3-bwcompat_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres_at_[hidden] >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

Generalized requests could still be used in single threaded mode with signals (SIGALRM) I think. Rajeev On Mar 8, 2011, at 1:09 PM, Dave Goodell wrote: > Sure, that sounds like a reasonable justification. I just wanted to make sure that you actually had that before you went forward to the Forum, since that's one of the things that I always ask when someone brings a new proposal to the whole group and it wasn't present on your original slides. > > -Dave > > On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: > >> I had to go back and read about generalized requests to remind myself how they worked... >> >> But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. >> >> So I think that the timers-as-requests idea still stands... >> >> >> On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: >> >>> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>>> >>>> Dave's point about generalized requests is a good one, though -- I need to go >>>> think about that and convince myself that what we're talking about isn't >>>> syntactic sugar and/or why it's better to be in the MPI implementation. >>> >>> In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. >>> >>> Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. >>> >>> -Fab >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> >> -- >> Jeff Squyres >> jsquyres_at_[hidden] >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

Yep -- I added it to my slides already. Thanks! On Mar 8, 2011, at 2:09 PM, Dave Goodell wrote: > Sure, that sounds like a reasonable justification. I just wanted to make sure that you actually had that before you went forward to the Forum, since that's one of the things that I always ask when someone brings a new proposal to the whole group and it wasn't present on your original slides. > > -Dave > > On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: > >> I had to go back and read about generalized requests to remind myself how they worked... >> >> But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. >> >> So I think that the timers-as-requests idea still stands... >> >> >> On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: >> >>> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>>> >>>> Dave's point about generalized requests is a good one, though -- I need to go >>>> think about that and convince myself that what we're talking about isn't >>>> syntactic sugar and/or why it's better to be in the MPI implementation. >>> >>> In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. >>> >>> Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. >>> >>> -Fab >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> >> -- >> Jeff Squyres >> jsquyres_at_[hidden] >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

Sure, that sounds like a reasonable justification. I just wanted to make sure that you actually had that before you went forward to the Forum, since that's one of the things that I always ask when someone brings a new proposal to the whole group and it wasn't present on your original slides. -Dave On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: > I had to go back and read about generalized requests to remind myself how they worked... > > But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. > > So I think that the timers-as-requests idea still stands... > > > On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: > >> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>> >>> Dave's point about generalized requests is a good one, though -- I need to go >>> think about that and convince myself that what we're talking about isn't >>> syntactic sugar and/or why it's better to be in the MPI implementation. >> >> In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. >> >> Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. >> >> -Fab >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > -- > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

I had to go back and read about generalized requests to remind myself how they worked... But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. So I think that the timers-as-requests idea still stands... On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: > Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >> >> Dave's point about generalized requests is a good one, though -- I need to go >> think about that and convince myself that what we're talking about isn't >> syntactic sugar and/or why it's better to be in the MPI implementation. > > In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. > > Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. > > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

Thanks. It looks like Dave got me: implied cancellation is not what looks practical. Better keep timeouts orthogonal, as you originally proposed. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier Sent: Monday, March 07, 2011 6:26 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests Hi Alexander, Your idea of post-conditioning a request wouldn't require any changes to existing APIs - I like it. The pre-conditioning however would make the request parameter inout to all functions that currently return one, which would break backward compatibility (users would need to initialize all input requests to MPI_REQUEST_NULL if they didn't have a pre-conditioned request). If you associate a timeout with individual requests, what happens to a request when it times out? Does it complete in error? Is it complete at all, or does the wait function simply return? One of the reasons for having separate timer requests rather than adding a timeout to existing requests is that the timeout condition remains completely local and doesn't indicate anything about outstanding I/O request. This leaves it up to the application to figure out how to handle the timeout. If an error, a send request could be cancelled, for example. Thanks, -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 07, 2011 4:05 AM Hi, The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": MPI_Isend(..., &req); MPI_Timer_set(MPI_Wtime() + 5, &req); ... MPI_Wait(&req); Or, for "preconditioning": MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ... MPI_Wait(&req); The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? Best regards. Alexander -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Friday, March 04, 2011 10:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 08 Mar '11

08 Mar '11

See your point, thanks. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Monday, March 07, 2011 6:36 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests What you are proposing amounts to a built-in version of "MPI_Cancel-after-timeout". So at the very least it has all of the downsides associated with cancel (esp. for send operations). It has the additional downside of forcing the MPI implementation to check all pending requests (that contain a timeout) for expiration. Other than my general dislike of message cancellation, I don't currently have a specific concern at this point, provided that the wording is sufficiently vague to permit timeout firing to be _very_ delayed. The multithreaded receive queue design that we sometimes use on Blue Gene would not permit this sort of cancellation in a timely fashion because it uses an additional, separate "fast post" queue in order to maximize message rate. Forcing timely timeouts would likely negate most of the performance benefit from such a design. Is there a good application use case for this functionality? Or is this just something amusing that is theoretically useful? -Dave On Mar 7, 2011, at 10:17 AM CST, Supalov, Alexander wrote: > Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa? > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Monday, March 07, 2011 4:28 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. > > -Dave > > On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > >> Hi, >> >> The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? >> >> As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": >> >> MPI_Isend(..., &req); >> MPI_Timer_set(MPI_Wtime() + 5, &req); >> ... >> MPI_Wait(&req); >> >> Or, for "preconditioning": >> >> MPI_Timer_create(MPI_Wtime() + 5, &req); >> MPI_Isend(..., &req); >> ... >> MPI_Wait(&req); >> >> The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell >> Sent: Friday, March 04, 2011 10:21 PM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI timer requests >> >> I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. >> >> I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. >> >> -Dave >> >> On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: >> >>> All -- >>> >>> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >>> >>> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >>> >>> Thanks! >>> >>> -- >>> Jeff Squyres >>> jsquyres_at_[hidden] >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> -------------------------------------------------------------------------------------- >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> Sitz der Gesellschaft: Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 >> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0