Initially, I used such an self written external program, say the
"sbd", it is normal, this program first perform execve() then execute
wait() and accompanies the main process to its completion, after which
it can either restart sbcl or clean up temporary files (either '.pid'
and '.lock' files). What I don't like is the fact that in such a
program one have to do extra work, I mean it must parse its arguments,
pass some arguments to SBCL, pass environment to SBCL, have a help
message, and all that "I the wrapper of the SBCL program" kind. In
addition, if we run "sbd --lock", then the new version of the SDB will
be blocked, but we can run SBCL with "sbcl" command, so that the
locking does not quite work because SBCL not changed itself.
So the question is whether the SBCL program should include a mechanism
of demonization or not ("all inclusive" or "use external tools"). If
yes, then this can be done by adding a few lines in runtime.с as in
that patch. As for the function QUIT, it is not necessary to modify,
if the supervisor is always run, he can assume the role of cleaning
'.pid' and '.lock' files.
2011/5/2, David Lichteblau <david@...>:
> Quoting Heka Treep (zena.treep@...):
>> 3) Implement all features in early runtime in SBCL (until threads of
>> the main process has't started). This solution has several advantages,
>> namely, we can add daemonization, restarts and locking that may
>> somehow depend on each other and be integrated into the runtime of
>> SBCL itself. Besides, it does not require a lot of code and provides a
>> simple interface in the form of options of the sbcl program. This
>> approach is similar to that used in other languages ??????with rich VMs
>> which have their own solution to demonization and related tasks (like
>> jsvc for Java, or Erlang's erl -detached option).
> Most of these features sound really cool; I'm personally a big fan of
> reliable daemon processes (think djb daemontools, albeit perhaps a
> little more userfriendly) and I agree that screen/detachtty, while
> sometimes nice, are not the right solution for everyone.
> However, it seems to me that most of these features could be implemented
> in a C program that then exec()s SBCL. One exception is the deletion
> of the lock file, but an exit hook can accomplish that without changes
> to SBCL.