<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3627" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=115354920-13012010><FONT face=Arial 
color=#0000ff size=2>Thanks. Do we know any active app that uses the JOIN still? 
If none, why the heck keep it afloat?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=115354920-13012010><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=115354920-13012010><FONT face=Arial 
color=#0000ff size=2>I meant CANCEL in all its varieties. Again, how many 
apps cannot live without it?</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpi3-ft-bounces@lists.mpi-forum.org 
[mailto:mpi3-ft-bounces@lists.mpi-forum.org] <B>On Behalf Of </B>Richard 
Treumann<BR><B>Sent:</B> Wednesday, January 13, 2010 9:48 PM<BR><B>To:</B> MPI 
3.0 Fault Tolerance and Dynamic Process Control working Group<BR><B>Subject:</B> 
Re: [Mpi3-ft] Nonblocking Process Creation and Management<BR></FONT><BR></DIV>
<DIV></DIV>
<P>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. 
<BR><BR>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.<BR><BR>Is it because 
IJOIN seems more difficult than IACCEPT and ICONNECT in some way?<BR><BR>When 
you say CANCEL should be deprecated, do you mean MPI_Cancel of an outstanding 
ISEND/IRECV request or something else?<BR><BR>Dick Treumann - MPI Team <BR>IBM 
Systems & Technology Group<BR>Dept X2ZA / MS P963 -- 2455 South Road -- 
Poughkeepsie, NY 12601<BR>Tele (845) 433-7846 Fax (845) 433-8363<BR><BR><BR><IMG 
height=16 
alt='Inactive hide details for "Supalov, Alexander" ---01/13/2010 02:53:18 PM---Thanks. I meant the JOIN per se as a way of establis' 
src="cid:115354920@13012010-134E" width=16 border=0><FONT 
color=#424282>"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</FONT><BR><BR>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
  <TBODY>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>From:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=1 border=0><BR><FONT size=2>"Supalov, Alexander" 
      <alexander.supalov@intel.com></FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>To:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=1 border=0><BR><FONT size=2>"MPI 3.0 Fault Tolerance and Dynamic 
      Process Control working Group" 
    <mpi3-ft@lists.mpi-forum.org></FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>Date:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=1 border=0><BR><FONT size=2>01/13/2010 02:53 PM</FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>Subject:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=1 border=0><BR><FONT size=2>Re: [Mpi3-ft] Nonblocking Process 
      Creation and Management</FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>Sent by:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:115354920@13012010-1355" 
      width=1 border=0><BR><FONT 
      size=2>mpi3-ft-bounces@lists.mpi-forum.org</FONT></TD></TR></TBODY></TABLE>
<HR style="COLOR: #8091a5" align=left width="100%" noShade SIZE=2>
<BR><BR><BR><TT>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.<BR><BR>Good point on the 
CANCEL.<BR><BR>-----Original Message-----<BR>From: 
mpi3-ft-bounces@lists.mpi-forum.org [</TT><TT><A 
href="mailto:mpi3-ft-bounces@lists.mpi-forum.org">mailto:mpi3-ft-bounces@lists.mpi-forum.org</A></TT><TT>] 
On Behalf Of Josh Hursey<BR>Sent: Wednesday, January 13, 2010 8:25 PM<BR>To: MPI 
3.0 Fault Tolerance and Dynamic Process Control working Group<BR>Subject: Re: 
[Mpi3-ft] Nonblocking Process Creation and Management<BR><BR>Since join() does a 
handshake to create the new communicator, it  <BR>should be delayed by the 
remote side of the protocol. A nonblocking  <BR>version would allow the 
application to possibly do other computation  <BR>while waiting for the 
remote side.<BR><BR>As far as Cancel, I have been thinking that it might be 
useful for  <BR>Accept and Connect. Though with the normal problems of 
Cancel, I don't  <BR>know how to really specify it. I want to look into it 
a bit more  <BR>before next week to see if anything useful can be said of 
using Cancel  <BR>with Accept/Connect.<BR><BR>-- Josh<BR><BR>On Jan 13, 
2010, at 2:01 PM, Supalov, Alexander wrote:<BR><BR>> Hi,<BR>><BR>> Do 
we really need the IJOIN thing? I think the JOIN itself should be  <BR>> 
deprecated. Just as CANCEL, by the way.<BR>><BR>> Best 
regards.<BR>><BR>> Alexander<BR>><BR>> -----Original 
Message-----<BR>> From: mpi3-ft-bounces@lists.mpi-forum.org [</TT><TT><A 
href="mailto:mpi3-ft-bounces@lists.mpi-forum.org">mailto:mpi3-ft-bounces@lists.mpi-forum.org</A></TT><TT> <BR>> 
] On Behalf Of Josh Hursey<BR>> Sent: Tuesday, January 12, 2010 11:04 
PM<BR>> To: MPI 3.0 Fault Tolerance and Dynamic Process Control working 
Group<BR>> Subject: [Mpi3-ft] Nonblocking Process Creation and 
Management<BR>><BR>> I extended and cleaned up the Nonblocking Process 
Creation and<BR>> Management proposal on the wiki:<BR>>   
 </TT><TT><A 
href="https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Async-proc-mgmt">https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Async-proc-mgmt</A></TT><TT><BR>><BR>> 
I added the rest of the nonblocking interface proposals, and touched<BR>> up 
some of the language. I do not have an implementation yet, but will<BR>> work 
on that next. There are a few items that I need to refine a bit<BR>> still 
(e.g., MPI_Cancel, mixing of blocking and nonblocking), but this<BR>> should 
give us a foundation to start from.<BR>><BR>> I would like to talk about 
this next week during our working group<BR>> slot at the MPI Forum 
meeting.<BR>><BR>> Let me know what you think, and if you see any 
problems.<BR>><BR>> Thanks,<BR>> Josh<BR>><BR>> 
_______________________________________________<BR>> mpi3-ft mailing 
list<BR>> mpi3-ft@lists.mpi-forum.org<BR>> </TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</A></TT><TT><BR>> 
---------------------------------------------------------------------<BR>> 
Intel GmbH<BR>> Dornacher Strasse 1<BR>> 85622 Feldkirchen/Muenchen 
Germany<BR>> Sitz der Gesellschaft: Feldkirchen bei Muenchen<BR>> 
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer<BR>> 
Registergericht: Muenchen HRB 47456 Ust.-IdNr.<BR>> VAT Registration No.: 
DE129385895<BR>> Citibank Frankfurt (BLZ 502 109 00) 
600119052<BR>><BR>> This e-mail and any attachments may contain 
confidential material for<BR>> the sole use of the intended recipient(s). Any 
review or distribution<BR>> by others is strictly prohibited. If you are not 
the intended<BR>> recipient, please contact the sender and delete all 
copies.<BR>><BR>><BR>> 
_______________________________________________<BR>> mpi3-ft mailing 
list<BR>> mpi3-ft@lists.mpi-forum.org<BR>> </TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</A></TT><TT><BR><BR>_______________________________________________<BR>mpi3-ft 
mailing list<BR>mpi3-ft@lists.mpi-forum.org<BR></TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</A></TT><TT><BR>---------------------------------------------------------------------<BR>Intel 
GmbH<BR>Dornacher Strasse 1<BR>85622 Feldkirchen/Muenchen Germany<BR>Sitz der 
Gesellschaft: Feldkirchen bei Muenchen<BR>Geschaeftsfuehrer: Douglas Lusk, Peter 
Gleissner, Hannes Schwaderer<BR>Registergericht: Muenchen HRB 47456 
Ust.-IdNr.<BR>VAT Registration No.: DE129385895<BR>Citibank Frankfurt (BLZ 502 
109 00) 600119052<BR><BR>This e-mail and any attachments may contain 
confidential material for<BR>the sole use of the intended recipient(s). Any 
review or distribution<BR>by others is strictly prohibited. If you are not the 
intended<BR>recipient, please contact the sender and delete all 
copies.<BR><BR><BR>_______________________________________________<BR>mpi3-ft 
mailing list<BR>mpi3-ft@lists.mpi-forum.org<BR></TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</A></TT><TT><BR></TT><BR><BR><pre>---------------------------------------------------------------------
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.
</pre></BODY></HTML>