On 11-03-11 02:53 AM, Marijn Haverbeke wrote:
I've started on a run-program library primitive, which invokes a
'shell' program. On Unix, this involves a call to fork(). I assume
fork-then-exec is safe, and will remain safe, since the forked process
will get only the thread the called fork, and exec will pretty much
reset the whole process (I'm closing fds manually), but I thought I'd
check.
Can anyone think of any problems, either now or in the future, with
this? I'm thinking of stacks switching and other funky multi-threading
techniques doing something the OS wasn't expecting.
(And what if I call fork but don't call exec? That might also be
useful at some point.)
If you have multiple tasks in a thread, they will all get replaced in a
exec. Given that we expose process/thread/task to the users, I think it
is reasonable to just return an error if the thread in question has more
than one task when executing an exec.
A direct use of fork+exec is probably safe:
*) Fork will fork all the tasks, but on both sides of the fork the
"same" task will get the result.
*) Exec will replace all the tasks on one side.
The net result is that one side of the fork has the tasks it had before
and the other side has just a new one.
Cheers,
Marijn
Cheers,
Rafael
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
