On Thu, 2005-03-24 at 00:17 +0100, Michael Rasmussen wrote: > It apparently seems to course problems when using Mono.Posix.fork. > My self compiled version under Debian runs flawlessly while giving these > errors under Fedora Core and Suse:
Don't call Syscall.fork unless you really know what you're doing... (Someone correct me if the following is wrong...) The problem is that Mono is implemented in terms of the Win32 API. This allows portability between Windows and Unix (io-layer implements a Win32 subset for Unix platforms). But in order to be efficient at some tasks, some data must be shared between all mono tasks. This data is in the ~/.wapi directory. (What data must be shared? Process Ids of processes created through System.Diagnostics.Process, so that you can efficiently wait for a child process to exit without resorting to polling. This is also why Process.GetProcesses() doesn't return *all* running processes, but only those that Mono created -- you can WaitForExit() on any one of them, and waitpid(2) only works for child processes.) The problem is that ~/.wapi data isn't (or can't be) properly protected against a random mono process calling fork(2), as this will duplicate handles in the child process, which will close those handles during the subsequent exec(2), which will royally screw up the parent process. - Jon PS: lupus: Is there any scenario where it's actually *safe* to call fork? I'm wondering if I should remove fork(2) and exec(2) from Mono.Unix.Syscall... Alternatively, is there someway to protected ~/.wapi so that fork(2) can be safely called? _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list