> The forkProcess# primitive has never worked 100% correctly; I'm
> currently trying to implement it for the threaded rts, and I see why.
> It's very hard to get it to work for more than a few special cases.
> Calling forkProcess from main (directly or indirectly, but there must
> be no foreign callbacks in between) should work fine.
> The standard idiom of of forking and execing in the child process
> should work from everywhere; the trouble only starts when the
> "forked"
> program tries to return from a foreign exported function or exits by
> terminating it's (only) thread.
>
> Using forkProcess# for anything else than the standard fork & exec
> combination is dangerous, and there seems to be nothing we
> can do about that.
I'd like to get forkProcess# fixed in 6.2, even if that means changing
the interface.
First, could you explain exactly the problems with implementing the
current version of forkProcess? Do we only run into problems when we
try to implement forkProcess in the threaded RTS?
In POSIX threads, fork() creates a new process containing a copy of the
current OS thread (only). So, AFAICT, this means that
(a) the RTS would need to adjust its idea of what worker threads
are available.
(b) if the Haskell thread that forked then exits:
(1) if was not a main thread, the RTS should exit
(2) if was a main thread, then
(i) if it was/is bound, we are ok, just return
(ii) if it was/is not bound, we have no OS thread to return
to, so the RTS must stop.
I don't see any real problems here, but I'm probably missing something.
Could you explain how your modified version of forkProcess# solves the
problems?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
