On 11/03/2011 8:23 AM, Rafael Avila de Espindola wrote:
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.
I wouldn't bother. Just pass through to libc. If a user is manually
calling exec from rust code, they are way off the 'unsafe' deep end.
They had better know what they're doing.
I feel the same way about fork. It's too system-specific, too unsafe,
has too many surprises as far as the tasking model. I'm not going to
prevent a user from calling it, might even give some guidance on what it
will do to the host rust process calling it, but it's outside the rust
tasking semantics to have the world suddenly duplicated on you.
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.
A "start an external subprocess we can talk to on pipes" call has
higher-level semantics. We should give library-support to that and not
say anything much about whether it's done by fork+exec, vfork,
posix_spawn, CreateProcess or whatever. It has utterly different
implementations depending on platform, and really should not effect the
tasks in the current domain.
(Indeed, for rust-spawning-rust we are going to provide an even
higher-level primitive that spawns a task from the current process in a
subprocess domain! But for rust-spawning-general-subprocess, pipes are
the best we can offer.)
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
