On 2017-12-02 02:26, Adam D. Ruppe wrote:

> But this is intentional - there is no generic, reliable, cross-platform way of handling it natively. So you need to know the system and code it yourself. Not super hard but does take a bit of effort in your code.

Since the "scope" block is not executed, does that also mean that the runtime is not shutdown? If that's the case, does it make sense to have a generic signal handler in druntime that aborts the application and shuts down the druntime in a graceful way?

-- 
/Jacob Carlborg

On Saturday, 2 December 2017 at 04:49:26 UTC, H. S. Teoh wrote:
> On Sat, Dec 02, 2017 at 04:38:29AM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
>> [...]
>
> Signal handlers can potentially be invoked while inside a non-reentrant libc or OS function, so trying to do anything that (indirectly or otherwise) calls that function will cause havoc to your program.  Also, while the signal handler is running, some (all?) further signals may be blocked, meaning that your program might miss an important signal if your sig handler takes too long to run.  Furthermore, the signal may have happened in the middle of your own code, so race conditions may apply (e.g. if you're modifying global data in both).
>
> [...]

On Linux you can use signalfd() for that, but nice trick if you want Posix portability.

On Sat, Dec 02, 2017 at 11:32:17AM +0000, Patrick Schluter via Digitalmars-d-learn wrote:
> On Saturday, 2 December 2017 at 04:49:26 UTC, H. S. Teoh wrote:
> > On Sat, Dec 02, 2017 at 04:38:29AM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> > > [...]
> > 
> > Signal handlers can potentially be invoked while inside a non-reentrant libc or OS function, so trying to do anything that (indirectly or otherwise) calls that function will cause havoc to your program.  Also, while the signal handler is running, some (all?) further signals may be blocked, meaning that your program might miss an important signal if your sig handler takes too long to run.  Furthermore, the signal may have happened in the middle of your own code, so race conditions may apply (e.g. if you're modifying global data in both).
> > 
> > [...]
> 
> On Linux you can use signalfd() for that, but nice trick if you want
> Posix portability.

Ha! I've been using Linux for decades now and this is the first time I'm aware of this function.  Should simplify my code when I'm not planning to be Posix-portable. Thanks!


T

-- 
Heads I win, tails you lose.

On Sunday, 3 December 2017 at 02:56:38 UTC, H. S. Teoh wrote:
> Ha! I've been using Linux for decades now and this is the first time I'm aware of this function.  Should simplify my code when I'm not planning to be Posix-portable. Thanks!

In the same vein, make sure you read about timerfd and eventfd too. They rok.