On Mon, 2008-11-03 at 14:49 -0800, Sixes wrote: > Jonathan Pryor wrote: > > On Wed, 2008-09-03 at 10:33 +0200, Robert Jordan wrote: > > > > Alas, I didn't get any further details, but that was enough for me to > > remove fork() from Syscall: if it can't ever be reliably called, then it > > shouldn't be callable. > > If you don't want to put System.Unix.Native.Syscall.fork() back in, how > about a simple, static System.Unix.Native.Daemon class? It could be > documented as only usable as the first call in Main().
That still wouldn't work, as *before* Main() is invoked there are already multiple threads running. You might not have the unknown lock state issue, but you will have the runtime assuming that threads exist which won't exist in the child process. Oops. So a "better" approach would be to look for the -d flag, and if present detach from the controlling terminal (forget what it is), respawn the current process via System.Diagnostics.Process w/o the -d flag, then exit. This sill create a child process that isn't attached to a terminal, thus doing (with more work) what daemon(3) would do... - Jon _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
