Thanks. Do we know any active app that uses the JOIN still?
If none, why the heck keep it afloat?
I meant CANCEL in all its varieties. Again, how many
apps cannot live without it?
Why would JOIN be any less useful today than in the past? Why would you want
to deprecate it? It is a trivial bootstrap for the simplest form of
ACCEPT/CONNECT. It just hides the ACCEPT and CONNECT operations and lets the
user handle the complexity of identifying the two end points any way he likes.
I never felt JOIN was needed very badly but it went in as a "what the
heck" decision and I do not see that anything has changed.
Is it because
IJOIN seems more difficult than IACCEPT and ICONNECT in some way?
When
you say CANCEL should be deprecated, do you mean MPI_Cancel of an outstanding
ISEND/IRECV request or something else?
Dick Treumann - MPI Team
IBM
Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road --
Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
"Supalov, Alexander" ---01/13/2010 02:53:18 PM---Thanks. I meant
the JOIN per se as a way of establishing the communicator. Do we need that
still? Wh
From: |
"Supalov, Alexander"
<alexander.supalov@intel.com> |
To: |
"MPI 3.0 Fault Tolerance and Dynamic
Process Control working Group"
<mpi3-ft@lists.mpi-forum.org> |
Date: |
01/13/2010 02:53 PM |
Subject: |
Re: [Mpi3-ft] Nonblocking Process
Creation and Management |
Sent by: |
mpi3-ft-bounces@lists.mpi-forum.org |
Thanks. I meant the JOIN per se as a way of establishing the
communicator. Do we need that still? What practically relevant cases can be
provided to justify its continuing existence? If there are none, we should
rather deprecate the JOIN and drop the IJOIN.
Good point on the
CANCEL.
-----Original Message-----
From:
mpi3-ft-bounces@lists.mpi-forum.org [mailto:mpi3-ft-bounces@lists.mpi-forum.org]
On Behalf Of Josh Hursey
Sent: Wednesday, January 13, 2010 8:25 PM
To: MPI
3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: Re:
[Mpi3-ft] Nonblocking Process Creation and Management
Since join() does a
handshake to create the new communicator, it
should be delayed by the
remote side of the protocol. A nonblocking
version would allow the
application to possibly do other computation
while waiting for the
remote side.
As far as Cancel, I have been thinking that it might be
useful for
Accept and Connect. Though with the normal problems of
Cancel, I don't
know how to really specify it. I want to look into it
a bit more
before next week to see if anything useful can be said of
using Cancel
with Accept/Connect.
-- Josh
On Jan 13,
2010, at 2:01 PM, Supalov, Alexander wrote:
> Hi,
>
> Do
we really need the IJOIN thing? I think the JOIN itself should be
>
deprecated. Just as CANCEL, by the way.
>
> Best
regards.
>
> Alexander
>
> -----Original
Message-----
> From: mpi3-ft-bounces@lists.mpi-forum.org [mailto:mpi3-ft-bounces@lists.mpi-forum.org
>
] On Behalf Of Josh Hursey
> Sent: Tuesday, January 12, 2010 11:04
PM
> To: MPI 3.0 Fault Tolerance and Dynamic Process Control working
Group
> Subject: [Mpi3-ft] Nonblocking Process Creation and
Management
>
> I extended and cleaned up the Nonblocking Process
Creation and
> Management proposal on the wiki:
>
https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Async-proc-mgmt
>
>
I added the rest of the nonblocking interface proposals, and touched
> up
some of the language. I do not have an implementation yet, but will
> work
on that next. There are a few items that I need to refine a bit
> still
(e.g., MPI_Cancel, mixing of blocking and nonblocking), but this
> should
give us a foundation to start from.
>
> I would like to talk about
this next week during our working group
> slot at the MPI Forum
meeting.
>
> Let me know what you think, and if you see any
problems.
>
> Thanks,
> Josh
>
>
_______________________________________________
> mpi3-ft mailing
list
> mpi3-ft@lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
---------------------------------------------------------------------
>
Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen
Germany
> 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 (BLZ 502 109 00)
600119052
>
> This e-mail and any attachments may contain
confidential material for
> the sole use of the intended recipient(s). Any
review or distribution
> by others is strictly prohibited. If you are not
the intended
> recipient, please contact the sender and delete all
copies.
>
>
>
_______________________________________________
> mpi3-ft mailing
list
> mpi3-ft@lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
_______________________________________________
mpi3-ft
mailing list
mpi3-ft@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
---------------------------------------------------------------------
Intel
GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
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 (BLZ 502
109 00) 600119052
This e-mail and any attachments may contain
confidential material for
the sole use of the intended recipient(s). Any
review or distribution
by others is strictly prohibited. If you are not the
intended
recipient, please contact the sender and delete all
copies.
_______________________________________________
mpi3-ft
mailing list
mpi3-ft@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
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 (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.