[Issue 20256] problem with signal handling and parallel GC on linux

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=20256

--- Comment #2 from igor.khasilev at gmail.com ---
(In reply to Rainer Schuetze from comment #1)
> I guess the same would happen with any other thread that has been created
> before forking. 

Yes, but developer is aware of the situation if he create tread himself. And
totally unaware and get unexpected program behavior if GC create thread. Or
will not receive unexpected behaviour if GC decide to start scan thread later
than sigprocmask were called.

> Not sure if this is something that can be solved in the
> runtime.


In runtime this can be solved by masking all signals before spawing GC thread
and restoring afterward. Something like
(https://github.com/dlang/druntime/blob/master/src/gc/impl/conservative/gc.d#L2824):

    version(Linux) {
        sigset_t old_mask, new_mask;
        sigemptyset(&new_mask);
        sigaddset(&new_mask, SIGHUP);
        sigaddset(&new_mask, SIGINT);
        ....
        sigaddset(&new_mask, SIGTERM);
        ...
        sigprocmask(SIG_BLOCK, &new_mask, &old_mask); // block anything for
scanBackgroung threads and store current mask
    }
    for (int idx = 0; idx < numScanThreads; idx++)
            scanThreadData[idx].tid = createLowLevelThread(&scanBackground,
0x4000, &stopScanThreads);
    version(Linux) {
        sigprocmask(SIG_UNBLOCK, &old_mask, null);
    }


> 
> It's been recently discussed to make parallel marking opt-in, so additional
> threads would not be created by default. See
> https://issues.dlang.org/show_bug.cgi?id=20219

this probably will help.

> 
> You can also embed the runtime option into the binary, see
> https://dlang.org/spec/garbage.html#gc_config

What if I am library author? I can't control this option, I'm just expect that
sigmask in main thread works for the whole process.

--