Hi all,
I'm attempting to write a simple daemon in mono that should background
itself after starting correctly. Essentially, it should fork() and
then the parent should exit(0) while the child process continues.
I've gotten this working with the (apparently now obsolete)
Mono.Posix.Syscall class
> Hi all,
>
> I'm attempting to write a simple daemon in mono that should
> background
> itself after starting correctly. Essentially, it should fork() and
> then the parent should exit(0) while the child process continues.
>
> I've gotten this working with the (apparently now obsolete)
> Mono.P
On Wed, Sep 3, 2008 at 12:16 AM, Bojan Rajkovic <[EMAIL PROTECTED]> wrote:
>> I'm attempting to write a simple daemon in mono that should
>> background
>> itself after starting correctly. Essentially, it should fork() and
>> then the parent should exit(0) while the child process continues.
>
> I b
Avery Pennarun wrote:
> However, I don't understand the rationale here. It seems to me that
> fork() has nothing to do with shutdown, and thus cannot possibly
> bypass "essential shutdown code." On the other hand, Syscall.execve
> is *not* obsolete and *does* bypass shutdown code. Furthermore, t
On Wed, 2008-09-03 at 10:33 +0200, Robert Jordan wrote:
> Avery Pennarun wrote:
> > However, I don't understand the rationale here. It seems to me that
> > fork() has nothing to do with shutdown, and thus cannot possibly
> > bypass "essential shutdown code." On the other hand, Syscall.execve
> >
On Wed, Sep 3, 2008 at 9:30 AM, Jonathan Pryor <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-09-03 at 10:33 +0200, Robert Jordan wrote:
>> If a child is calling exit() upon termination, parent's handles will
>> be closed as well. This will most likely break parts of the runtime
>> (io-layer, etc.).
>>
On Wed, 2008-09-03 at 12:23 -0400, Avery Pennarun wrote:
> So my next question then is: is there any way to get mono to *not* use
> threads unless you explicitly ask it to do so? It seems like just the
> GC and JIT are threads right now, right? Actually I don't know enough
> to even describe why
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.
>
Sorry about jumping in two months l
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
Jonathan Pryor wrote:
> 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.
>
>
Isn't t
On Wed, 2008-11-05 at 22:13 +, James Mansion wrote:
> Jonathan Pryor wrote:
> > 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
On Wed, Nov 5, 2008 at 6:20 PM, Jonathan Pryor <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-11-05 at 22:13 +, James Mansion wrote:
>> Jonathan Pryor wrote:
>> > That still wouldn't work, as *before* Main() is invoked there are
>> > already multiple threads running. You might not have the unknown
Jonathan Pryor wrote:
> 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 attach
> It seems to me that the one valid reason to fork() is to detach from the
> controlling terminal. This can (and should) be done before starting any
> threads other than Main(). So long as it is done right at the beginning, it
> seems unlikely it will cause problems.
You can do this in your scrip
On Wed, Nov 5, 2008 at 4:45 PM, Cliff Stanford <[EMAIL PROTECTED]> wrote:
> I don't want to turn this into a language argument but my feeling was
> that mono was allowing C# to become a serious Unix programming language.
>
> Becoming a daemon is a common part of Unix programming. I don't know
> a
2008/11/5 Phil Garcia <[EMAIL PROTECTED]>:
> In fact, threads were added to POSIX
> to cope with the limitations and inefficiencies of fork() and the
> programming model around it.
Of course, you could also say the same about running processes in
separate address spaces, which were eventually adde
16 matches
Mail list logo
