Re: SIGUSR1, SIGUSR2
On Friday, 11 December 2020 at 17:32:54 UTC, Adam D. Ruppe wrote: On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote: But somehow my process gets signalled with USR1 and USR2 all the time. If I do The garbage collector uses sig usr1/2 to pause threads so it can do its collection work. When debugging just ignore them. My .gdbinit has these lines: handle SIGUSR1 noprint handle SIGUSR2 noprint since most D programs will have these. For lldb breakpoint set -n _Dmain --auto-continue true -N OnMain breakpoint command add -o "pro hand -p true -s false -n false SIGUSR1 SIGUSR2" OnMain does the trick.
Re: SIGUSR1, SIGUSR2
On Friday, 11 December 2020 at 17:32:54 UTC, Adam D. Ruppe wrote: On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote: But somehow my process gets signalled with USR1 and USR2 all the time. If I do The garbage collector uses sig usr1/2 to pause threads so it can do its collection work. When debugging just ignore them. My .gdbinit has these lines: handle SIGUSR1 noprint handle SIGUSR2 noprint since most D programs will have these. Thanks, good to know!
Re: SIGUSR1, SIGUSR2
On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote: But somehow my process gets signalled with USR1 and USR2 all the time. If I do The garbage collector uses sig usr1/2 to pause threads so it can do its collection work. When debugging just ignore them. My .gdbinit has these lines: handle SIGUSR1 noprint handle SIGUSR2 noprint since most D programs will have these.
SIGUSR1, SIGUSR2
I have as vibe.d application that opens some websockets, reads messages and does something with them (currently mostly writing them to disk). The processing happens in background threads started with runWorkerTask, the websocket code runs as a normal task (runTask), everything is synchronized over a central circular buffer. But somehow my process gets signalled with USR1 and USR2 all the time. If I do $ strace -etrace=epoll_wait the disruptions of epoll by SIGUSR1/2 just scroll down. According to the strace output I got new, the source of the signals is the process itself. This happens if I do not install a signal handler myself. While this makes debugging a pain, at least the program seems to work. If I install signal handlers for USR1/USR2 via eventcore than vibe.d never seems to be able to establish the websocket connection. The same happens if I do signal(SIGUSR1, SIG_IGN). Maybe some kind of deadlock (all threads seem to be waiting on some condition variables or a in a spinlock). Does anyone have a idea what's going on here?
