From: Leslie P. P. <sk...@vi...> - 2009-04-30 07:00:36
|
I have a need to recreate the original command-line that SBCL was called with. The attached patch makes this possible; let me know if there's a better or already existing way to do this. diff --git a/src/runtime/runtime.c b/src/runtime/runtime.c index 45f7eec..c3bfb7d 100644 --- a/src/runtime/runtime.c +++ b/src/runtime/runtime.c @@ -206,6 +206,7 @@ search_for_core () } char **posix_argv; +char **orig_argv; char *core_string; struct runtime_options *runtime_options; @@ -226,6 +227,8 @@ main(int argc, char *argv[], char *envp[]) os_vm_offset_t embedded_core_offset = 0; char *runtime_path = 0; + orig_argv = argv; + /* other command line options */ boolean noinform = 0; boolean end_runtime_options = 0; |
From: Nikodemus S. <nik...@ra...> - 2009-04-30 08:12:42
|
2009/4/30 Leslie P. Polzer <sk...@vi...>: > I have a need to recreate the original command-line that > SBCL was called with. Can you explain the use case you have? Cheers, -- Nikodemus |
From: Leslie P. P. <sk...@vi...> - 2009-04-30 08:44:55
|
> 2009/4/30 Leslie P. Polzer <sk...@vi...>: > >> I have a need to recreate the original command-line that >> SBCL was called with. > > Can you explain the use case you have? Yes. One of my apps slowly leaks memory. I haven't been able to pinpoint the cause of this (perhaps it's the conservative GC). So I'd rather like to check regularly for the remaining space and in time do a clean shutdown and call exec() to set up a new SBCL instance. I could hardcode the args or record them in some file but I'd rather just use the original arguments. Leslie |
From: Nikodemus S. <nik...@ra...> - 2009-04-30 09:14:42
|
2009/4/30 Leslie P. Polzer <sk...@vi...>: > >> 2009/4/30 Leslie P. Polzer <sk...@vi...>: >> >>> I have a need to recreate the original command-line that >>> SBCL was called with. >> >> Can you explain the use case you have? > > Yes. One of my apps slowly leaks memory. I haven't been > able to pinpoint the cause of this (perhaps it's the > conservative GC). > > So I'd rather like to check regularly for the remaining > space and in time do a clean shutdown and call exec() > to set up a new SBCL instance. Here's an alternative approach: (defun funcall-in-child (fun &rest args) (let ((pid (sb-posix:fork))) (if (zerop pid) (apply fun args) (sb-posix:waitpid pid 0)))) (loop (funcall-in-child #'my-application)) Cheers, -- Nikodemus |
From: Leslie P. P. <sk...@vi...> - 2009-04-30 09:31:47
|
> Here's an alternative approach: > > (defun funcall-in-child (fun &rest args) > (let ((pid (sb-posix:fork))) > (if (zerop pid) > (apply fun args) > (sb-posix:waitpid pid 0)))) > > (loop (funcall-in-child #'my-application)) That's an interesting approach but I would prefer not to modify the application directly (nor its mode of invocation). Is there a disadvantage with making the original argv list available? It might be useful for other purposes, too. Leslie |
From: Nikodemus S. <nik...@ra...> - 2009-04-30 09:59:08
|
2009/4/30 Leslie P. Polzer <sk...@vi...>: > That's an interesting approach but I would prefer not to > modify the application directly (nor its mode of invocation). I don't understand your meaning. fork + waitpid, then refork is pretty much equivalent to (my-application) (reexec-lisp) -- neither requires modifying the application. That said, I believe a wrapper process (shell script, whatever) is a robuster way to do this: a process cannot unwedge itself, but a wrapper can kill it if its resource consumption goes out of bounds, etc. > Is there a disadvantage with making the original argv list > available? It might be useful for other purposes, too. I can't think of a *disadvantage* as such offhand, but it seems mildly subversive. Cheers, -- Nikodemus |
From: Leslie P. P. <sk...@vi...> - 2009-04-30 10:15:45
|
> That said, I believe a wrapper process (shell script, whatever) is a > robuster way to do this: a process cannot unwedge itself, but a > wrapper can kill it if its resource consumption goes out of bounds, > etc. I find it easier to detect and manage non-fatal environment conditions from the Lisp app itself. With more serious issues you're right of course. Anyway it's just a minor convenience issue for me so I'll leave it at your discretion whether to make argv available or not. Thanks! Leslie |