Some portion of program is scriptable with ECL, which runs in its own separate thread. What I fear, however, is that users might do something stupid and enter an infinite loop or break into debugger wondering why does the scriptable part no longer responds. For the latter breaking into debugger is disabled by default with an option to reenable it, but nevertheless knowing Murphy's law I expect the worst to happen. I would like to keep the program responsive no matter what.
I was hoping I could restart ECL in such cases, so I tried terminating ECL thread first but it results in a crash. And apparently after calling cl_shutdown ECL shuts down for good and a second call to cl_boot does not work so restarting does not appear as an option anyway.
Is there anything I can do to keep the program running or just trust the user to do the right thing?
Hey,
given scarce amount of details this may be inaccurate, but if I had such issue I'd do what follows:
start main ECL thread and spawn a thread with the user script in it. Function running in this process would look something in this spirit:
(loop while (null *exit*) do (handler-case (si:toplevel) (serious-condition (c) (format *debug-io* "something is wrong:~%~a~%~@ Yes, starting over." c))))
Since it will be in a separate thread, you may safely interrupt it or even destroy to start over. You may put your own repl in the handler-case body and i.e wrap each REP iteration in with-timeout.
Regarding problems with cl_boot, cl_shutdown, cl_boot please report an issue on our bugtracker.
N.b at some point of time I'd love to see a functionality in ECL where whole runtime is stored in a single variable, so we could have N different ECL instances running in the same process, but I don't think it will happen anytime soon.
ecl_call_with_runtime(ecl_ptr, "(si::toplevel)");
Best regards, Daniel
Не Скажу writes:
Some portion of program is scriptable with ECL, which runs in its own separate thread. What I fear, however, is that users might do something stupid and enter an infinite loop or break into debugger wondering why does the scriptable part no longer responds. For the latter breaking into debugger is disabled by default with an option to reenable it, but nevertheless knowing Murphy's law I expect the worst to happen. I would like to keep the program responsive no matter what.
I was hoping I could restart ECL in such cases, so I tried terminating ECL thread first but it results in a crash. And apparently after calling cl_shutdown ECL shuts down for good and a second call to cl_boot does not work so restarting does not appear as an option anyway.
Is there anything I can do to keep the program running or just trust the user to do the right thing?
-- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
-
Daniel Kochmański -
Не Скажу