On Tuesday, 1 October 2013 at 08:01:21 UTC, Jacob Carlborg wrote:
> On 2013-10-01 06:54, PauloPinto wrote:
>
>> I would say the main reason is that anyone can replace the current set
>> of signals, thus breaking what might be druntime's signal handling.
>
> If druntime has a default signal handler and the user replaces that. It's up to the user to call the original signal handler so everything is properly destructed/finalized.
>
> It's the same problem with the GC and all the other handlers that druntime has that the user can override.
>
> I would consider these very advanced features and not something a user should be fiddling with every day.

I just remember that you also have the added problem that signal handlers are very limited in what you are allowed to do, with the set of restrictions and guarantees not being portable across all POSIX systems.

Specially the tricks of notifying the application a signal has happened, after signal returns and the whole story of redoing interrupted system calls.

--
Paulo

This is a really good question, I think! Python has a KeyboardInterrupt exception for this purpose. Should we perhap try something similar? Perhaps as a library solution? I think a function like some_module.registerInterruptExceptions() would be cool to have. If someone knows a way to do that, that would be cool. I'm looking at deadalnix...

On Monday, 30 September 2013 at 22:55:22 UTC, H. S. Teoh wrote:
> On Mon, Sep 30, 2013 at 08:44:36PM +0200, deadalnix wrote:
>> On Monday, 30 September 2013 at 02:13:47 UTC, H. S. Teoh wrote:
>> >Well, ctrl-C can be handled, so the way I'd do it is to set up a
>> >signal handler for SIGINT and have it write something to a self-pipe
>> >read by the event handler, then the event handler can throw an
>> >Exception (which should cause dtors to run as the stack unwinds).
>> >
>> 
>> No you can't.
>> 
>> But you somehow can, if you want to use some black magic :
>> http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/
>
> We were talking about SIGINT, not SIGSEGV.
>

That isn't relevant here.

On Tue, Oct 01, 2013 at 02:06:12PM +0200, deadalnix wrote:
> On Monday, 30 September 2013 at 22:55:22 UTC, H. S. Teoh wrote:
> >On Mon, Sep 30, 2013 at 08:44:36PM +0200, deadalnix wrote:
> >>On Monday, 30 September 2013 at 02:13:47 UTC, H. S. Teoh wrote:
> >>>Well, ctrl-C can be handled, so the way I'd do it is to set up a signal handler for SIGINT and have it write something to a self-pipe read by the event handler, then the event handler can throw an Exception (which should cause dtors to run as the stack unwinds).
> >>>
> >>
> >>No you can't.
> >>
> >>But you somehow can, if you want to use some black magic : http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/
> >
> >We were talking about SIGINT, not SIGSEGV.
> >
> 
> That isn't relevant here.

Huh? The OP was talking about cleaning up after ctrl-C, not after a segfault. I already know you can't throw exceptions from a segfault (except with heavy trickery, and yes I remember the post you linked and I know how it works).

SIGINT is different because it can be handled, and the signal handler can just write a byte to a pipe read by the main event loop, outside of signal handler context.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

On Tuesday, 1 October 2013 at 14:53:24 UTC, H. S. Teoh wrote:
> On Tue, Oct 01, 2013 at 02:06:12PM +0200, deadalnix wrote:
>> On Monday, 30 September 2013 at 22:55:22 UTC, H. S. Teoh wrote:
>> >On Mon, Sep 30, 2013 at 08:44:36PM +0200, deadalnix wrote:
>> >>On Monday, 30 September 2013 at 02:13:47 UTC, H. S. Teoh wrote:
>> >>>Well, ctrl-C can be handled, so the way I'd do it is to set up a
>> >>>signal handler for SIGINT and have it write something to a
>> >>>self-pipe read by the event handler, then the event handler can
>> >>>throw an Exception (which should cause dtors to run as the stack
>> >>>unwinds).
>> >>>
>> >>
>> >>No you can't.
>> >>
>> >>But you somehow can, if you want to use some black magic :
>> >>http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/
>> >
>> >We were talking about SIGINT, not SIGSEGV.
>> >
>> 
>> That isn't relevant here.
>
> Huh? The OP was talking about cleaning up after ctrl-C, not after a
> segfault. I already know you can't throw exceptions from a segfault
> (except with heavy trickery, and yes I remember the post you linked and
> I know how it works).
>
> SIGINT is different because it can be handled, and the signal handler
> can just write a byte to a pipe read by the main event loop, outside of
> signal handler context.
>

The signal handler cannot throw exception. If you want to do so, you need the same scafolding.

ctrl+c send a signal to the program. The exact same system need to be used to throw.

Obviously, you can flag something on ctrl+c so you quit you main loop, which is simpler, but not what I was answering to.

On 2013-10-01 13:19, PauloPinto wrote:

> I just remember that you also have the added problem that signal
> handlers are very limited in what you are allowed to do, with the set of
> restrictions and guarantees not being portable across all POSIX systems.
>
> Specially the tricks of notifying the application a signal has happened,
> after signal returns and the whole story of redoing interrupted system
> calls.

druntime already handles SIGSEGV signals, at least for Linux:

https://github.com/D-Programming-Language/druntime/blob/master/src/etc/linux/memoryerror.d

-- 
/Jacob Carlborg

On Tuesday, 1 October 2013 at 03:58:04 UTC, Nick Sabalausky wrote:
> You know, this sounds like something that really should fall squarely in
> the category of "do the right thing by default". Is there any reason
> druntime can't be made to handle this better by default?

Well, arguably, a segfault is a catastrophic error, even more serious than an assert.

I'm not sure what "the right thing" would even be, apart from dying right there and then...?

Even just throwing an error could be problematic (AFAIK).

On Tuesday, 1 October 2013 at 18:16:27 UTC, Jacob Carlborg wrote:
> On 2013-10-01 13:19, PauloPinto wrote:
>
>> I just remember that you also have the added problem that signal
>> handlers are very limited in what you are allowed to do, with the set of
>> restrictions and guarantees not being portable across all POSIX systems.
>>
>> Specially the tricks of notifying the application a signal has happened,
>> after signal returns and the whole story of redoing interrupted system
>> calls.
>
> druntime already handles SIGSEGV signals, at least for Linux:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/etc/linux/memoryerror.d

Is this feature working as built-in or by demand?

On Tuesday, 1 October 2013 at 19:55:17 UTC, monarch_dodra wrote:
> On Tuesday, 1 October 2013 at 03:58:04 UTC, Nick Sabalausky wrote:
>> You know, this sounds like something that really should fall squarely in
>> the category of "do the right thing by default". Is there any reason
>> druntime can't be made to handle this better by default?
>
> Well, arguably, a segfault is a catastrophic error, even more serious than an assert.

In linux assert(0) causes a segfault. And the fact that detected by OS memory error is sigfault at linux and exception on windows really hurts portability.

> I'm not sure what "the right thing" would even be, apart from dying right there and then...?
>
> Even just throwing an error could be problematic (AFAIK).

Druntime can catch SIGINT and throw the exception. This means that D runtime can be easily broken by silly C code which uses its own signal handlers. I didn't tested, but believe this is already the case with respect to SIGUSR1 and SIGUSR2 which are used by druntime, so any simple code hijacking the signals can break runtime. Linux signals handlers as error mechanism is a complete disaster.

On Tue, 01 Oct 2013 21:55:16 +0200
"monarch_dodra" <monarchdodra@gmail.com> wrote:

> On Tuesday, 1 October 2013 at 03:58:04 UTC, Nick Sabalausky wrote:
> > You know, this sounds like something that really should fall
> > squarely in
> > the category of "do the right thing by default". Is there any
> > reason
> > druntime can't be made to handle this better by default?
> 
> Well, arguably, a segfault is a catastrophic error, even more serious than an assert.
> 
> I'm not sure what "the right thing" would even be, apart from dying right there and then...?
> 
> Even just throwing an error could be problematic (AFAIK).

I'm not talking about segfaults, I'm talking about the OP's issue of a mere Ctrl-C causing cleanup code to not get executed.