[Mono-devel-list] Re: Mono-devel-list digest, Vol 1 #1576 - 3 msgs

[Jonathan Pryor]

On Sat, 2005-04-02 at 05:10 +0200, Michael Rasmussen wrote:
> This is fine if you want to call an external function in unmanage code
> but in my case this is not want I want. I want to be able to start an
> application written in C# and then, if so requested, fork the entire
> application to the background running as a daemon.

It appears that this won't be possible, at least for now.  The primary
reason is that Mono is multi-threaded by default -- a "Hello World"-
style program has 3 threads active by default (I don't know what they're
doing, but I'm seeing 3 process id's in /proc/PID/task under Linux, and
IIRC each "task" is a thread).

Since it appears that TLS data isn't preserved after the fork(2) call,
you can't do a P/Invoke call at all after a fork -- meaning I should
remove fork and exec from Mono.Unix.Syscall, and replace the pair of
them with a MS-DOS "spawn" equivalent (or just skip the whole thing and
have people use System.Diagnostics.Process instead, which sounds better
all the time...).

To fix this, we'd either need to (a) have only 1 thread active by
default, or (b) find a way to do P/Invoke without using TLS.  I'm not
sure how practical either of these solutions is.

> Maybe I have missed an importing thing about your solutions, but in my
> opinion they does not meet my requirements. As far as I have been able
> to test with my prototypes it all work as intended in my specific case
> due to the fact that it seems mono simply copies the functionality from
> bg on unix - running the task as a background process in the current
> shells environment see IEEE Std 1003.1.
> 
> I could off course make a wrapper in C which forked off by calling mono
> with exec but that is not very portable and undermines the hole idea
> behind C#.

You could write a wrapper in sh(1), and avoid the C code. :-)

This is especially attractive, as the mono convention is to provide a
shell script to start your program (/usr/bin/mcs is a shell-script), so
you could modify this shell script to run "nohup mono myprogram.exe" if
your --background option is specified.

As for portability, you've lost portability as soon as you use
Mono.Unix, which (except for Stdlib and related classes) will only run
under Unix-like platforms.  If you're on a Unix-like platform, you
should be able to add your own P/Invoke calls relying upon unix
functionality.

I think we also have differing opinions behind the "whole idea behind
C#".  It is not a Java replacement, attempting to provide "write once,
run anywhere" portability -- just looking at System.Windows.Forms should
reinforce this.  Mono/C# is an environment allowing greater productivity
while still making the most of your target platform.  If you can do this
while being portability, so much the better, but Mono won't try to
ensure portability.  The ease of P/Invoke should reinforce this view.

 - Jon