Search
Wednesday, 18th of May 2022, 16:46:27 UTC
16:52:22
edgar-rft
I still have a CP/M machine, what SBCL version would you recommend? :-)
23:37:07
dbotton
what would be the best way to tell sbcl that on an error to not go debugger but also not exit either, so that the app continues to run?
23:40:19
|3b|
restart-case, restart-bind, ignore-errors, etc (not the last one though in most cases)
23:40:57
|3b|
or maybe i meant handler-bind handler-case
23:41:55
|3b|
yeah, probably handler-case is one to start with
23:43:54
dbotton
that is not always possible as the errors don't seem to make it to my code, ie they happen in hutchentoot
23:43:56
|3b|
(not specific to sbcl though)
23:44:24
|3b|
hunchentoot probably has some way to specify that too i think
23:44:41
dbotton
what I am looking for (if exists) a command line method to say print an error, don't go in to the debugger, and don't exit sbcl
23:44:59
dbotton
I'd prefer something more global, forced
23:45:01
mfiano
Use handler-casse to handle hunchentoot's specific condition in the best way for your application
23:45:10
mfiano
Or handler-bind if you don't want to unwind the stack
23:45:26
dbotton
I've place tones of hadler-cases every where
23:46:04
dbotton
It seems these happen in threads that I can't seem to track down related to using clack
23:46:11
|3b|
well, you can play with *debugger-hook* if you hate your users (including future you)
23:46:18
mfiano
(handler-case (progn your-code) (hunchentoot:name-of-condition-type (e) (format t "Some message instead of error")))
23:46:29
dbotton
it is for production use
23:46:56
dbotton
errors are very varied over the last 6 months of production testing
23:46:59
|3b|
hunchentoot:*catch-errors-p* isn't working?
23:49:15
mfiano
If you are entering the debugger you are not handling the correct condition type.
23:49:23
mfiano
Or you are handling it wrong.
23:49:41
dbotton
or not in the right thread'
23:50:17
|3b|
ACTION isn't sure what sbcl could reasonably do beyond what the spec provides, aside from maybe kill individual threads instead of whole thing, but not sure even that would be all that safe
23:50:31
mfiano
If you are using multiple threads then you might want to look into bt:make-thread's bindings argument, or similar for other abstractions.
23:51:05
dbotton
|3b| that is idea, ie the bad thread dies but no the whole app
23:51:19
dbotton
If I ran multiple websites in a single lisp image.....
23:51:27
|3b|
silently, with no log messages?
23:51:44
dbotton
sure can log, just don't want sbcl to exit
23:51:54
|3b|
no, thread is dead, can't log :p
23:52:47
dbotton
well you know what I mean
23:53:19
dbotton
how did lisp machines work, one app crashed an whole system crashed?
23:53:57
|3b|
debugger was presumably OK on lisp machines
23:54:09
|3b|
or people handled the errors
23:57:37
dbotton
I currently run live sites in a tmux so that the debugger is running, but that is not ideal in a large site
23:58:31
|3b|
yeah, web server should be handling making sure threads don't end up in debugger
23:59:10
|3b|
no idea if clack is doing things outside hunchentoot's attempt at that, or if something is breaking what hunchentoot does
23:59:16
mfiano
If you use clack you can easily switch out the web server for something else.
23:59:22
mfiano
Without changing any code
23:59:30
|3b|
(not everyone gets things right when printing the backtrace to logs errors for example)
23:59:40
mfiano
Personally I use woo in production
23:59:53
mfiano
and hunchentoot during interactive use
0:04:15
|3b|
ACTION wouldn't expect there to be too many types of threads being created though, so seems like it wouldn't take too many times to find which place isn't handling errors properly and patch/bug-report/whatever it
0:07:54
dbotton
*debugger-hook* didn't work either
0:09:12
|3b|
do you have a backtrace from an example?
0:12:16
dbotton
hmmm now can't break system...
0:12:38
dbotton
perhaps those were old reads before putting in the debugger hook
0:15:34
dbotton
no dice... go figure. the errors are broken pipes when they do occur, mostly in the websockets
2:23:03
dbotton
is there a good way to keep sbcl alive when running as a process?
2:23:17
dbotton
sorry system process
2:24:05
dbotton
I can sleep for long time, but is there some sort of simple way to keep alive sbcl when there are are other processes still running
2:26:41
mfiano
busy-wait while your other threads run in the background
2:45:20
mfiano
:toplevel (lambda () (start-other-stuff) (loop (sleep 1)))
2:45:35
mfiano
or something along those lines
2:46:05
mfiano
assuming other stuff is not on the main thread
3:05:53
dbotton
https://www.reddit.com/r/lisp/comments/usttdy/how_to_setup_common_lisp_websites_in_this_case/
3:06:10
dbotton
I put up directions for next guy :)
3:29:17
stassats
(loop (sleep 1)) is a good way to waste cpu cycles
3:29:33
dbotton
Is there a better way?
3:29:48
stassats
wait on whatever you are waiting
3:30:01
dbotton
I am not waiting on anything
3:30:03
stassats
like, if all you do is sleep, what is it useful for?
3:30:07
dbotton
just need to keep sbcl alive
3:30:27
dbotton
if I do not wait, sbcl is closed
3:30:38
dbotton
my other threads are shutdown
3:31:08
dbotton
it seems that there is little awareness in sbcl of threads
3:31:27
dbotton
so that an error in one thread shutsdown sbcl
3:31:59
dbotton
if a condition is not caught, and no-debugger setup sbcl comes down
3:32:18
stassats
what else can it do
3:32:26
dbotton
kill the bad thread
3:32:32
dbotton
keep the rest running
3:33:02
dbotton
it makes no sense that one broken pipe on a website can take down a 100 users
3:33:16
stassats
sbcl can't write code for you
3:33:35
dbotton
for some reason I can't catch the occasional broken pipe in hutchentoot
3:34:00
dbotton
but regardless it doesn't seem a good behavior
3:34:25
dbotton
for a production system to shutdown for a thread with an uncaught condition
3:34:32
stassats
you disabled the debugger, you not are not catching any errors
3:34:37
stassats
so your production system is bad
3:35:00
dbotton
a headless system is just that
3:35:16
dbotton
I log the errors and deal with later
3:35:22
stassats
then make it do that
3:35:53
dbotton
for the most part it does. but for some reason even setting debugger hooks doesn't catch all
3:36:22
stassats
that can't be true
3:36:30
dbotton
I wish it was the case
3:36:47
stassats
which means it's not done correctly
3:36:49
dbotton
for months been chasing bugs in others code, adding handler-cases etc
3:37:33
dbotton
do you have an example that would 100% prevent an error you can help me with?
3:37:50
dbotton
meaning catch the error, and passively continue.
3:42:16
stassats
(setf *debugger-hook* (lambda (c h) c h (sb-thread:abort-thread)))
3:42:42
dbotton
I'll give it a try, thanks
3:43:36
stassats
if you have --disable-debugger, you'll either need to remove it or use sb-ext:*invoke-debugger-hook* instead
3:46:29
dbotton
I'l make sure not present
3:46:48
dbotton
will have to work on though tomorrow. appreciated
3:47:26
stassats
and for not exiting, hunchentoot creates a thread, you can get a hold of it and do join-thread on it
3:48:28
dbotton
is sleep that costly?
3:48:42
dbotton
like in the case of a sleep 360
3:49:21
stassats
you might want to do something if that thread dies
3:49:30
stassats
as you won't be able to silently continue
3:50:17
dbotton
if the main thread dies systemd is going to close the service
3:50:37
stassats
that is not the main thread though
3:53:30
stassats
something like (sb-thread:join-thread (hunchentoot::acceptor-process (hunchentoot::acceptor-taskmaster acceptor)))
3:53:47
stassats
should probably be part of hunchentoot
3:55:27
stassats
can also use (sb-thread:abort-thread :allow-exit t) to exit the main thread on errors too
3:56:49
stassats
and don't forget --disable-ldb
3:56:56
stassats
and --lose-on-corruption for a good measure
Thursday, 19th of May 2022, 4:46:27 UTC