[Mono-list] Mono: TLS. normal versus __thread

[Jonathan Pryor]

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?