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

igor.khasilev@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |igor.khasilev@gmail.com

--

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

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de

--- Comment #1 from Rainer Schuetze <r.sagitario@gmx.de> ---
I guess the same would happen with any other thread that has been created before forking. Not sure if this is something that can be solved in the runtime.

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

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

--

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

--- Comment #2 from igor.khasilev@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.

--

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

--- Comment #3 from igor.khasilev@gmail.com ---
To be clear - I'm not against parallel GC, just against unexpected behavior. I can spend time and prepare PR if it hav any chance to be accepted.

--

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

--- Comment #4 from Rainer Schuetze <r.sagitario@gmx.de> ---
(In reply to igor.khasilev from comment #3)
> I can spend time and prepare PR if it hav any chance to be accepted.

That would be great. I'm not a posix/linux expert, so help is appreciated.

--

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

--- Comment #5 from igor.khasilev@gmail.com ---
Hello, Rainer!

PR created https://github.com/dlang/druntime/pull/2811

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #6 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ikod updated dlang/druntime pull request #2811 "fix issue 20256" fixing this issue:

- fix issue 20256 - (linux) block signals in parallel gc scan thread

- fix issue 20256 - (linux) block signals in parallel gc scan thread

- fix issue 20256

https://github.com/dlang/druntime/pull/2811

--

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

--- Comment #7 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ikod created dlang/druntime pull request #2813 "problem with signal handling and parallel GC on linux" fixing this issue:

- fix issue 20256 - problem with signal handling and parallel GC on linux

- fix issue 20256 - problem with signal handling and parallel GC on linux

https://github.com/dlang/druntime/pull/2813

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/druntime pull request #2813 "problem with signal handling and parallel GC on linux" was merged into stable:

- 0217ac2af215f78e3a41bbbfa3ccc6f54f457aca by Igor Khasilev:
  fix issue 20256 - problem with signal handling and parallel GC on linux

https://github.com/dlang/druntime/pull/2813

--