freenode/#sbcl - IRC Chatlog
Search
8:01:52
karlosz
can anyone think of pros and cons for having the free pointer be in a static symbol a la arm vs dedicating a reg for it like most riscs?
9:23:00
flip214
I've got a few lines using trivial-signal; but catching/handling signals only works in a new thread, not in the main thread.
9:23:49
flip214
when using (xxx) directly in a (load ...), the signal is caught only once; with the additional thread it works more often.
11:35:56
stassats
minion: memo for karlosz: it's going to go into the thread object anyway, so don't bother too much
11:43:21
stassats
or at least do it in a safer way, have a thread that polls on an FD, and writing to that FD when receiving a signal
12:52:08
flip214
stassats: I would have thought that a thread that waits in a loop and only sets a variable when receiving a signal is already fairly safe?! Not doing any IO from the signal handler -- which is the recommended way to go, AFAIK.
12:53:07
flip214
and trivial-signal is careful to allow the given signal _only_ on the specific thread (blocks on others)
12:53:36
flip214
and yes, signalling a specific thread is possible as well - but t-s doesn't require that, signalling the process is good enough.
12:58:41
stassats
i don't see a single call to pthread_sigmask in https://github.com/guicho271828/trivial-signal/tree/master/src
13:00:13
flip214
> The C-level signal handlers call a lisp function, which interrupts each thread who has thread-local signal handlers established by signal-handler-bind.
13:10:15
flip214
why do you say that using a kernel-based notification mechanism that takes up 2 file handles is safer or easier than writing to some variable?
13:16:27
flip214
if signalling the _main_ thread did work correctly, the sleep would even be terminated at the same time!
13:17:37
flip214
well, sorry, that sounds a bit silly. yeah, a spinlock might use a delay when congested, but with that kind of sleep I wouldn't call it a "spinning lock".
13:20:52
flip214
if signals would work in the main thread as well, it would be more of a mutex - which is what you'd recommend, anyway
13:24:16
flip214
code flow gets changed via a TAGBODY in the t-s example, and via NEXT-ITERATION (which results in a TAGBODY too) in my paste - so the SLEEP isn't waited for
13:24:48
flip214
in my paste, if you comment out the extra-thread variant and use the (xxx) directly, signalling only works once