D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 6846 - std.concurrency and fork/execv
Summary: std.concurrency and fork/execv
Status: RESOLVED INVALID
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: x86 Linux
: P2 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-23 14:22 UTC by Jonathan Sternberg
Modified: 2016-05-09 22:57 UTC (History)
1 user (show)

See Also:


Attachments
example code from description (1015 bytes, text/x-dsrc)
2011-10-23 14:22 UTC, Jonathan Sternberg
Details

Note You need to log in before you can comment on or make changes to this issue.
Description Jonathan Sternberg 2011-10-23 14:22:30 UTC
Created attachment 1042 [details]
example code from description

Attached is a sample program that I believe should work, but doesn't. The
program is a simple command runner.

It runs a maximum of 4 processes at once and each process is just "echo
<number>". The command runner uses "spawn" to create a new thread. This thread
then immediately forks and calls execv in the child. The parent then waits on
the newly created process. When it finishes, it sends it's tid and the exit
status of the command.

When run, sometimes a thread will seem to stall on the execv call. It seems
that the fork happened successfully, but a quick check with "ps" will reveal
that two processes named "test" exist (the forked one should have been
replaced).

The program then has no way to continue by itself. The only way to make it
continue is to call "kill" on the newly created processes.
Comment 1 anonymous4 2015-02-20 08:12:28 UTC
You allocate in a forked process. Try to use spawnProcess instead, it tries to avoid complex operations after fork.
Comment 2 Vladimir Panteleev 2016-05-09 22:57:49 UTC
You are mixing threads with forking. This is a bad idea in any language.

What happens is that a thread from the main process forks, but it doesn't take along with it the other threads. One of those threads is running the GC, which holds a lock. As the GC thread is not duplicated during the fork, the lock will never be freed, thus the forked process will deadlock.