> which raises some issues with the Shepherd init system (towards the > end in the section "Robustness and failure modes"), in particular > with its use of an interpreted and garbage collected language. i > was wondering if anyone here with knowledge about this would care to > comment on the validity of these concerns?
I just skimmed it and it looks like the typical ignoramus FUD. The author cannot even tell the difference between an interpreter and a VM. Also amusing is this quote: "JITs can do amazing things, at least in memory usage." I presume the author here is confusing JITs with tracing or profile-directed run-time optimization (another mistake common to people who do not understand dynamic language run-times). Yes, those can indeed do amazing things in memory usage, namely using up gigantic amounts of it. There is about 50 years worth of applications in using dynamic languages for systems programming (starting with BBN LISP/Interlisp). The biggest problem is bounding garbage collection pauses. There are various ways to do this (the simplest being to pre allocate memory). As for handling running out of memory, the author could have answered his own question by taking a minute to search through the Guile sources: gc-malloc.c:139 scm_report_out_of_memory (); throw.c:639 throw_without_pre_unwind (scm_out_of_memory_key, out_of_memory_args); And indeed in NEWS: Instead of aborting, failures to allocate memory will now raise an unwind-only `out-of-memory' exception, and cause the corresponding `catch' expression to run garbage collection in order to free up memory. So you catch the exception and perform some appropriate action. Here I am not exactly sure what the appropriate thing for an init system to do would be - fail at starting a new service? Vladimir
