sharedfp/lockedfile and sm: fix name collision #3105
Conversation
this fixes the issue reported by Nicolas Joly on the mailing: the sharedfp/lockedfile component does not support right now a scenario where multiple jobs read from the same input file, due to a collision of the filenames utilized for the sharedfp handle. Although not part of the oroginal report, the same occurs for the sharedfp/sm component. Add therefore the jobid to be part of the lockedfilename/sm file name. use the OMPI_CAST_RTE_NAME macro to determine jobid Fixes: open-mpi#3098 Signed-off-by: Edgar Gabriel <egabriel@central.uh.edu>
|
@edgargabriel do you consider this an "edge" case? Or is it a common enough use case that we need to spin another rc candidate for v2.1.0? I'm learning toward the edge case and moving the milestone for this to v2.1.1. I would be okay with this leading to another rc if the report came from part of rc testing, but it looks like the user was working with 2.0.1 |
|
It is probably more an edge case. The way I would look at it is: if you need to spin another rc candidate anyway, we could integrate this pr as well. Otherwise lets wait for 2.1.1 |
|
@jsquyres I think we should go ahead and merge in since we're waiting on other fixes anyway. |
|
Per discussion on the Webex today, we're going to merge this because the mallopocalypse is going to force another rc. |
this fixes the issue reported by Nicolas Joly on the mailing: the sharedfp/lockedfile component does not support right now a scenario where multiple jobs read from the same input file, due to a collision of the filenames utilized for the sharedfp handle. Although not part of the oroginal report, the same occurs for the sharedfp/sm component. Add therefore the jobid to be part of the lockedfilename/sm file name.
use the OMPI_CAST_RTE_NAME macro to determine jobid
Fixes: #3098
Signed-off-by: Edgar Gabriel egabriel@central.uh.edu