Recently, I've worked with some other users who have needed to spawn child subprocesses from their OpenSHMEM applications. This process took us through three different implementation paths:

• Typically, one would call fork()→exec(). Unfortunately, this does not seem to work portably [*], as some SHMEM libraries seg-fault at the fork() call.
• In the course of experimentation, users found that calling vfork()→exec() worked portably [*], but vfork() was marked obsolete in POSIX-2001, removed from POSIX-2008, and is not without its critics (ref: 1, 2).
• Using posix_spawn() seems to work portably [*]. (Somewhat ironically, it uses vfork() under the hood on Linux.)`

[*] where "portably" means "across all the OpenSHMEM implementations to which I have access, all of which are running on Linux".

To be clear, the child processes -- either after fork() or after exec() -- will not make any calls into the OpenSHMEM library. The application is not calling fork() without an exec(). (Of secondary interest may be the case in which the application calls fork() but does not call exec(). I haven't seen applications that do this, since I would think threads would be preferred.)

Should the OpenSHMEM specification take a position on interoperability with fork()?