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?

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.

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!

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.