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.
>

It shouldn't in a language that have nullable type as default.

On Tuesday, 1 October 2013 at 20:06:46 UTC, Maxim Fomin wrote:
> 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?

By demand.

Call registerMemoryErrorHandler to enable it and deregisterMemoryErrorHandler to rollback.

On Tuesday, 1 October 2013 at 20:42:59 UTC, Nick Sabalausky wrote:
> 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.

The question discussed here is how to throw an exception when a signal is received. It doesn't really matter if this is because of a segfault or because of ctrl+c .

As this work as been done for segfault, it make sense to refers to it.

On Tuesday, October 01, 2013 22:16:04 Maxim Fomin wrote:
> 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.

As I understand it, the problem is that there isn't really another mechanism to do what druntime is using signals for. So, we're between a bit of a rock and a hard place. Ideally though, we would find a way to do it without using signals.

- Jonathan M Davis

On Tuesday, October 01, 2013 23:17:01 deadalnix wrote:
> 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.
> 
> It shouldn't in a language that have nullable type as default.

I don't see why that's relevant. If you hit a segfault - regardless of whether it's because of a memory corruption or a null pointer or whatever - it's an error that should terminate your program. If we checked for null pointers and threw NullPointerError instead of segfaulting, it would be no different except that it would be an Error being thrown. Both it and segfaults are supposed to kill your program without doing cleanup.

- Jonathan M Davis

Am 01.10.2013 22:16, schrieb Maxim Fomin:
> 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.

s/Linux/UNIX/g

On Tuesday, 1 October 2013 at 23:32:38 UTC, Paulo Pinto wrote:
> s/Linux/UNIX/g

The described technique use some OS specific features. It can be adapted to OSX as far as I know, but POSIX do not guarantee to have all required features to implement this.

On 10/01/2013 10:06 PM, Maxim Fomin wrote:
>
> Is this feature working as built-in or by demand?

This can't be built-in because signal handlers are global and you cannot anticipate in which environments druntime get used.

On 10/1/2013 3:37 PM, Jonathan M Davis wrote:
> On Tuesday, October 01, 2013 23:17:01 deadalnix wrote:
>> It shouldn't in a language that have nullable type as default.
>
> I don't see why that's relevant. If you hit a segfault - regardless of whether
> it's because of a memory corruption or a null pointer or whatever - it's an
> error that should terminate your program. If we checked for null pointers and
> threw NullPointerError instead of segfaulting, it would be no different except
> that it would be an Error being thrown. Both it and segfaults are supposed to
> kill your program without doing cleanup.

Right. A null pointer dereference is a logic bug in your program, and hence the program needs to stop immediately, not execute "cleanup" code.

If there's one notion I'd like to terminate with prejudice, it's the notion that a running program can "recover" from bugs in itself.

On 10/02/2013 12:37 AM, Jonathan M Davis wrote:
> As I understand it, the problem is that there isn't really another mechanism
> to do what druntime is using signals for. So, we're between a bit of a rock
> and a hard place. Ideally though, we would find a way to do it without using
> signals.
>
> - Jonathan M Davis

What we need is pthread_suspend and the ability to determine the stack top of the suspended thread. That would also allow for some nice unification of core.thread. I already have that on my TODO list, low prio though. I think I saw a solution to this in some other GC (V8 maybe?).