Daemonize v0.1 - simple way to create cross-platform daemons

[NCrashed via Digitalmars-d-announce]

> IIRC, I read in your code that composed signals means the next
> delegate must have the (logger, signal) {...} form.
> Why?
I can (not must) have the form, the delegate params are tested 
independently from signal composition.

> Is that the standard behavior for daemons in OSes?
Most signals are simply ignored (except termination ones).

> You could have the daemon stopped, after logging the unhandled 
> signal.
> Or you could also block compilation if a daemon does not handle 
> all signals...
Some signals could be sent without any reason: sighup or 
interrogate in windows.
Ignoring most signals is a better strategy, the exception could 
be done for terminating signals - their default handlers should 
set `shouldExit` flag to true.

> Or have a 'catch-all' delegate, as std.concurrency.receive, 
> which uses
> a (Variant v) {...} delegate at the end.
> See:
> http://dlang.org/library/std/concurrency/receive.html
Good idea, it will be implemented.

> (btw, signals could also be types and you could have a handling 
> syntax
> similar to receive).
Ohh, that is much more complicated feature as it may seem. 
Signaling in both OSes are very limited. We need an additional 
channel to pass arbitrary memory between processes and also 
restrict data to be serializable. If I continue to move in that 
direction, the D will occasionally obtain a library for 
distributed cluster computing (like Cloud Haskell) ;).

On Sunday, 31 August 2014 at 19:45:32 UTC, Philippe Sigaud via 
Digitalmars-d-announce wrote:
>>> Does the user sees/uses this name in any way afterwards? 
>>> Because I
>>> think you could also produce a unique string at compile-time 
>>> (by using
>>> __FILE__ and __LINE__, unless someone has a better idea), if 
>>> the user
>>> does not provide one. Maybe he just wants an anonymous 
>>> daemon, or
>>> doesn't care, whatever.
>>
>> Yes, the name is used in windows service manager (you can 
>> start/stop the
>> daemon by control panel) and for default locations of .pid and 
>> .lock files.
>
> OK.
>
>> Auto generated name will prevent sending signals and could be 
>> ugly displayed
>> in service manager. The feature is useful for simple daemons, 
>> I will play
>> around with that idea to find out if it worth.
>
> Great.
>
>
>> I will add the approach in next release (it requires some more 
>> additional
>> templates to wrap all the mess) thanks to arguments "grammar" 
>> has no
>> ambiguities.
>
> Yes, the grammar is simple, use it to simplify the life of your 
> users.
>
>>> Is the idea that, if the delegate has two arguments, then the 
>>> second
>>> is the signal that will be passed to it, and if it has only 
>>> one
>>> argument, only the logger will be passed?
>>
>> Yes
>
> OK.
> IIRC, I read in your code that composed signals means the next
> delegate must have the (logger, signal) {...} form.
> Why?
>
>
>>> What if the user does not want a logger? Is a daemon always 
>>> associated
>>> to a log file in OSes?
>>
>> It is a general rule as the stderr and stdout files are 
>> closed. At next
>> version I want to use duck typing for logger (or sink approach 
>> same as
>> toString uses) and add a feature to reopen stderr/stdout to 
>> another file.
>
> OK.
>
>
>>> Concerning the DaemonClient template, could you not ask for 
>>> Daemon to
>>> generate it on demand? Or is DaemonClient always used in 
>>> another
>>> module?
>>
>> DaemonClient is designed to be used in another module, you can 
>> send signals
>> with full Daemon template.
>
> OK. I'd have thought that just having the name of the daemon 
> would be
> enough to send it signals.
>
>>> What happens when an unhandled signal is passed to a daemon?
>>
>> The event is logged down and ignored.
>
> Is that the standard behavior for daemons in OSes?
> You could have the daemon stopped, after logging the unhandled 
> signal.
> Or you could also block compilation if a daemon does not handle 
> all signals...
> Or have a 'catch-all' delegate, as std.concurrency.receive, 
> which uses
> a (Variant v) {...} delegate at the end.
> See:
> http://dlang.org/library/std/concurrency/receive.html
>
> (btw, signals could also be types and you could have a handling 
> syntax
> similar to receive).