That sounds fine with me, George. Just to clarify: My comment about differing interpretations didn't pertain to this specific question, but was more an observation of some discussions we have had about such issues in other areas. I didn't talk to anyone about this particular question, just noted that someone on the MPI side originally wrote the code and probably had some interpretation of how it should work in mind.
Or maybe not... :-) Anyway, I can easily add some code in the DPM to ensure we close any still open ports at finalize of that framework, if you feel that is the right place to do it. Since people are -supposed- to call MPI_Close_port to close the port, and since that code calls the DPM to execute that function, that framework should have a clear picture of what is still open. Make sense? Ralph On 4/25/08 5:19 PM, "George Bosilca" <bosi...@eecs.utk.edu> wrote: > Ralph, > > Thanks for your concern regarding the level of compliance of our > implementation of the MPI standard. I don't know who were the MPI > gurus you talked with about this issue, but I can tell that for once > the MPI standard is pretty clear about this. > > As stated by Aurelien in his last email, using the plural in several > sentences, strongly suggest that the status of port should not be > implicitly modified by MPI_Comm_accept or MPI_Comm_connect. Moreover, > in the beginning of the chapter in the MPI standard, it is specified > that comm/accept work exactly as in TCP. In other words, once the port > is opened it stay open until the user explicitly close it. > > However, not all corner cases are addressed by the MPI standard. What > happens on MPI_Finalize ... it's a good question. Personally, I think > we should stick with the TCP similarities. The port should be not only > closed by unpublished. This will solve all issues with people trying > to lookup a port once the originator is gone. > > george. > > On Apr 25, 2008, at 5:25 PM, Ralph Castain wrote: > >> As I said, it makes no difference to me. I just want to ensure that >> everyone >> agrees on the interpretation of the MPI standard. We have had these >> discussion in the past, with differing views. My guess here is that >> the port >> was left open mostly because the person who wrote the C-binding >> forgot to >> close it. ;-) >> >> So, you MPI folks: do we allow multiple connections against a single >> port, >> and leave the port open until explicitly closed? If so, then do we >> generate >> an error if someone calls MPI_Finalize without first closing the >> port? Or do >> we automatically close any open ports when finalize is called? >> >> Or do we automatically close the port after the connect/accept is >> completed? >> >> Thanks >> Ralph >> >> >> >> On 4/25/08 3:13 PM, "Aurélien Bouteiller" <boute...@eecs.utk.edu> >> wrote: >> >>> Actually, the port was still left open forever before the change. The >>> bug damaged the port string, and it was not usable anymore, not only >>> in subsequent Comm_accept, but also in Close_port or Unpublish_name. >>> >>> To more specifically answer to your open port concern, if the user >>> does not want to have an open port anymore, he should specifically >>> call MPI_Close_port and not rely on MPI_Comm_accept to close it. >>> Actually the standard suggests the exact contrary: section 5.4.2 >>> states "it must call MPI_Open_port to establish a port [...] it must >>> call MPI_Comm_accept to accept connections from clients". Because >>> there is multiple clients AND multiple connections in that >>> sentence, I >>> assume the port can be used in multiple accepts. >>> >>> Aurelien >>> >>> Le 25 avr. 08 à 16:53, Ralph Castain a écrit : >>> >>>> Hmmm...just to clarify, this wasn't a "bug". It was my understanding >>>> per the >>>> MPI folks that a separate, unique port had to be created for every >>>> invocation of Comm_accept. They didn't want a port hanging around >>>> open, and >>>> their plan was to close the port immediately after the connection >>>> was >>>> established. >>>> >>>> So dpm_orte was written to that specification. When I reorganized >>>> the code, >>>> I left the logic as it had been written - which was actually done by >>>> the MPI >>>> side of the house, not me. >>>> >>>> I have no problem with making the change. However, since the >>>> specification >>>> was created on the MPI side, I just want to make sure that the MPI >>>> folks all >>>> realize this has now been changed. Obviously, if this change in spec >>>> is >>>> adopted, someone needs to make sure that the C and Fortran >>>> bindings - >>>> do not- >>>> close that port any more! >>>> >>>> Ralph >>>> >>>> >>>> >>>> On 4/25/08 2:41 PM, "boute...@osl.iu.edu" <boute...@osl.iu.edu> >>>> wrote: >>>> >>>>> Author: bouteill >>>>> Date: 2008-04-25 16:41:44 EDT (Fri, 25 Apr 2008) >>>>> New Revision: 18303 >>>>> URL: https://svn.open-mpi.org/trac/ompi/changeset/18303 >>>>> >>>>> Log: >>>>> Fix a bug that rpevented to use the same port (as returned by >>>>> Open_port) for >>>>> several Comm_accept) >>>>> >>>>> >>>>> Text files modified: >>>>> trunk/ompi/mca/dpm/orte/dpm_orte.c | 19 ++++++++++--------- >>>>> 1 files changed, 10 insertions(+), 9 deletions(-) >>>>> >>>>> Modified: trunk/ompi/mca/dpm/orte/dpm_orte.c >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> =================================================================== >>>>> --- trunk/ompi/mca/dpm/orte/dpm_orte.c (original) >>>>> +++ trunk/ompi/mca/dpm/orte/dpm_orte.c 2008-04-25 16:41:44 EDT >>>>> (Fri, 25 Apr >>>>> 2008) >>>>> @@ -848,8 +848,14 @@ >>>>> { >>>>> char *tmp_string, *ptr; >>>>> >>>>> + /* copy the RML uri so we can return a malloc'd value >>>>> + * that can later be free'd >>>>> + */ >>>>> + tmp_string = strdup(port_name); >>>>> + >>>>> /* find the ':' demarking the RML tag we added to the end */ >>>>> - if (NULL == (ptr = strrchr(port_name, ':'))) { >>>>> + if (NULL == (ptr = strrchr(tmp_string, ':'))) { >>>>> + free(tmp_string); >>>>> return NULL; >>>>> } >>>>> >>>>> @@ -863,15 +869,10 @@ >>>>> /* see if the length of the RML uri is too long - if so, >>>>> * truncate it >>>>> */ >>>>> - if (strlen(port_name) > MPI_MAX_PORT_NAME) { >>>>> - port_name[MPI_MAX_PORT_NAME] = '\0'; >>>>> + if (strlen(tmp_string) > MPI_MAX_PORT_NAME) { >>>>> + tmp_string[MPI_MAX_PORT_NAME] = '\0'; >>>>> } >>>>> - >>>>> - /* copy the RML uri so we can return a malloc'd value >>>>> - * that can later be free'd >>>>> - */ >>>>> - tmp_string = strdup(port_name); >>>>> - >>>>> + >>>>> return tmp_string; >>>>> } >>>>> >>>>> _______________________________________________ >>>>> svn mailing list >>>>> s...@open-mpi.org >>>>> http://www.open-mpi.org/mailman/listinfo.cgi/svn >>>> >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
