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

[NCrashed via Digitalmars-d-announce]

Thanks a lot for the respond!

> 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. 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.

> If I understand correctly, the Daemon template waits for a list 
> of (at
> least one) Signal, then a delegate, then some more Signals, 
> another
> delegate, and so on?
>
> If that's so I think you could ditch KeyValueList (or build it
> invisibly to the user) and let the user write only the signals 
> and
> delegates:
>
> alias daemon = Daemon!(
>     Signal.Terminate, Signal.Quit, Signal.Shutdown, Signal.Stop,
>     (logger, signal) {
>     ...},
>     Signal.Hangup,
>     (logger) {
>     ...}
> ...
> );
>
> Iterate the argument list, collecting Signals. When you hit a
> delegate, create a Composition!( ... ) with the previous 
> signals, jump
> above the delegate and so on.
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.

> 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

> 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.

> Is the main function always the last delegate?
Yes

> 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.

> What happens when an unhandled signal is passed to a daemon?
The event is logged down and ignored.

> Do you foresee any difficulty in adapting this to Mac?
All logic should be the same as for linux, I just don't have any 
machine to test
all out. I hope virtual machine will help.

On Sunday, 31 August 2014 at 16:01:10 UTC, Philippe Sigaud via 
Digitalmars-d-announce wrote:
> Nice!
>
> I have a few questions/remarks, mainly to simplify the API 
> somewhat.
> Please bear with me :-)
>
>> // First you need to describe your daemon via template
>> alias daemon = Daemon!(
>>     "DaemonizeExample1", // unique name
>
> 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.
>
>
>>     // Setting associative map signal -> callbacks
>>     KeyValueList!(
>
> If I understand correctly, the Daemon template waits for a list 
> of (at
> least one) Signal, then a delegate, then some more Signals, 
> another
> delegate, and so on?
>
> If that's so I think you could ditch KeyValueList (or build it
> invisibly to the user) and let the user write only the signals 
> and
> delegates:
>
> alias daemon = Daemon!(
>     Signal.Terminate, Signal.Quit, Signal.Shutdown, Signal.Stop,
>     (logger, signal) {
>     ...},
>     Signal.Hangup,
>     (logger) {
>     ...}
> ...
> );
>
> Iterate the argument list, collecting Signals. When you hit a
> delegate, create a Composition!( ... ) with the previous 
> signals, jump
> above the delegate and so on.
>
> 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?
>
> What if the user does not want a logger? Is a daemon always 
> associated
> to a log file in OSes?
>
>
>>
>>     // Main function where your code is
>>     (logger, shouldExit) {
>>         // will stop the daemon in 5 minutes
>>         auto time = Clock.currSystemTick +
>> cast(TickDuration)5.dur!"minutes";
>>         while(!shouldExit() && time > Clock.currSystemTick) {  
>> }
>>
>>         return 0;
>>     }
>
> Is the main function always the last delegate?
>
> Concerning the DaemonClient template, could you not ask for 
> Daemon to
> generate it on demand? Or is DaemonClient always used in another
> module?
>
> Because, given a Daemon, extracting the simplified DaemonClient 
> can be
> done, I think.
>
>
>> * Custom signals
>
> enum Signal : string
> { ... }
>
> @nogc Signal customSignal(string name) @safe pure nothrow
> {
>     return cast(Signal)name;
> }
>
> I didn't know you could have an enum and extend it with a cast 
> like this. Wow.
>
>
>> * Signal composition
>
> What happens when an unhandled signal is passed to a daemon?
>
>
>> P.S. At the moment library doesn't support Mac and other Posix 
>> systems, the
>> support is going to be added at next releases.
>
> Do you foresee any difficulty in adapting this to Mac?