We have some legacy code which creates tmp files using:
/tmp/<pid>_<unique_id> where unique_id is a globally incremented counter
within the process.
The <pid> above is generated using getpid().
As typically executed outside of DMTCP, each process gets a unique PID, and
there are no tmp file collisions if we run N of these on a cluster node.
However, running under dmtcp_launch, getpid() is returning a virtualized
pid (initialized to 40000). When we run N of these on a cluster node, we
get tmp file collisions (ex. multiple processes dealing with /tmp/40000_1
at the same time). It is often a race condition, but with enough jobs it
collides pretty reliably.
>From reading the docs, there is a lot of design history w/r to pid
virtualization, and of course some virtualization has to be there in the
restart case.
What to do about the above problem? Am I missing something silly here? I
can't see a way around this.
Clearly, there are other ways to come up with unique tmp files (mktmp,
etc.), but it is desirable this legacy code runs unmodified.
Any thoughts appreciated.
--
-Kyle
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Dmtcp-forum mailing list
Dmtcp-forum@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
