On Thu, May 16, 2019 at 11:37 PM Nicolas Koenig
wrote:
>
> Hi everyone,
>
> a quick heads up, that the native coarray patch I'm working on at the
> moment (1200 loc and growing :D) will be based upon forked processes, so
> we won't be able to eliminate fork().
I would guess that's a case where fo
On Thu, May 16, 2019 at 11:54 PM Thomas Koenig wrote:
>
> Hi Janne,
>
> > I differ there.
>
> A longer explanation:
>
> fork() is standard POSIX.
So is posix_spawn, as the name implies.
>Not all systems have posix_spawn.
Do you know of any target we support that has fork but not posix_spawn?
>
Hi Janne,
I differ there.
A longer explanation:
fork() is standard POSIX. Not all systems have posix_spawn. For
those systems which do not have it, we would cause a regression
by simply removing that functionality for this.
The patch is OK from my side if you add fork() as a fallback option
Am 16.05.19 um 22:10 schrieb Janne Blomqvist:
On Thu, May 16, 2019 at 10:59 PM Thomas Koenig wrote:
Hi Janne,
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https://www.micros
On Thu, May 16, 2019 at 10:59 PM Thomas Koenig wrote:
>
> Hi Janne,
>
> > fork() semantics can be problematic. Most unix style OS'es have
> > posix_spawn which can be used to replace fork + exec in many cases.
> > For more information see
> > e.g.
> > https://www.microsoft.com/en-us/research/upl
Hi Janne,
fork() semantics can be problematic. Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
This replaces the one use of fork in libgf
