On 10/2/2013 10:10 AM, Sean Kelly wrote:
>> 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.
>
> I worked on a system whose design was specifically built around trapping and
> recovering from segfaults (great design, and sadly, patented).  Things like
> this are one of the primary reasons to use a systems programming language.
> So while I agree in the general sense, I don't think it's appropriate for the
> language to make a hard and fast assertion here.  I think we should choose a
> reasonable, safe default, but make it overridable.  That's pretty much the
> design philosophy of Druntime.

D being a systems programming language, you can pursue whatever design you like with it, including bad designs :-)

Although I haven't seen the system you describe, I'm very skeptical that it found the solution to the problem of a program successfully continuing after it has crashed due to program bugs. I remain firmly convinced that that is an utterly wrong and doomed approach to the problem of reliability.

On Thursday, 3 October 2013 at 00:25:26 UTC, Walter Bright wrote:
> Although I haven't seen the system you describe, I'm very skeptical that it found the solution to the problem of a program successfully continuing after it has crashed due to program bugs. I remain firmly convinced that that is an utterly wrong and doomed approach to the problem of reliability.

Segfaults aren't necessarily bugs... though I'm not sure if a userspace handler can do much about it. But from a kernel perspective, they can be generated by page faults too, which can be successfully handled by loading the requested memory block (e.g. from a swap file) and then retrying the operation, or copying the page into a writable location and mapping that in; hardware assisted copy-on-write.

I've never tried to do this in a unix program so I don't know how much you can do, but presumably Sean's example did something along these lines, so it would be by design rather than bugs.

On 10/2/2013 6:15 PM, Adam D. Ruppe wrote:
> Segfaults aren't necessarily bugs... though I'm not sure if a userspace handler
> can do much about it. But from a kernel perspective, they can be generated by
> page faults too, which can be successfully handled by loading the requested
> memory block (e.g. from a swap file) and then retrying the operation, or copying
> the page into a writable location and mapping that in; hardware assisted
> copy-on-write.

That's true, and in fact I implemented a generational GC once that relied on catching seg faults from invalid writes to keep track of which pages were 'dirty'. It did work fine, although it turned out to be too slow.


> I've never tried to do this in a unix program so I don't know how much you can
> do, but presumably Sean's example did something along these lines, so it would
> be by design rather than bugs.

If that is the design, then I misunderstood it.

On Oct 2, 2013, at 5:25 PM, Walter Bright <newshound2@digitalmars.com> wrote:
> 
> On 10/2/2013 10:10 AM, Sean Kelly wrote:
>>> 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.
>> 
>> I worked on a system whose design was specifically built around trapping and recovering from segfaults (great design, and sadly, patented).  Things like this are one of the primary reasons to use a systems programming language. So while I agree in the general sense, I don't think it's appropriate for the language to make a hard and fast assertion here.  I think we should choose a reasonable, safe default, but make it overridable.  That's pretty much the design philosophy of Druntime.
> 
> D being a systems programming language, you can pursue whatever design you like with it, including bad designs :-)
> 
> Although I haven't seen the system you describe, I'm very skeptical that it found the solution to the problem of a program successfully continuing after it has crashed due to program bugs. I remain firmly convinced that that is an utterly wrong and doomed approach to the problem of reliability.

It isn't a program bug in this case though. This is essentially an object database that lazily maps in chunks of the data store on demand. The objects are then used directly from mapped memory without any intermediate loading thanks to some dirty tricks played to guarantee vtbl placement in application memory across releases. Ridiculously fast and it allows large databases to be used efficiently. This backs an accounting system used by large trading firms.

In any case, my point remains that some features like this can be part of a good design in rare cases. So systems languages shouldn't flat out prevent them, but rather put an "experts only" label on there somewhere.

On Oct 2, 2013, at 6:15 PM, "Adam D. Ruppe" <destructionator@gmail.com> wrote:
> 
>> On Thursday, 3 October 2013 at 00:25:26 UTC, Walter Bright wrote:
>> Although I haven't seen the system you describe, I'm very skeptical that it found the solution to the problem of a program successfully continuing after it has crashed due to program bugs. I remain firmly convinced that that is an utterly wrong and doomed approach to the problem of reliability.
> 
> Segfaults aren't necessarily bugs... though I'm not sure if a userspace handler can do much about it. But from a kernel perspective, they can be generated by page faults too, which can be successfully handled by loading the requested memory block (e.g. from a swap file) and then retrying the operation, or copying the page into a writable location and mapping that in; hardware assisted copy-on-write.
> 
> I've never tried to do this in a unix program so I don't know how much you can do, but presumably Sean's example did something along these lines, so it would be by design rather than bugs.

This exactly. It goes a bit beyond what Posix allows in signal handlers, but it works just fine on this particular system.

On 10/2/2013 8:04 PM, Sean Kelly wrote:
> It isn't a program bug in this case though. This is essentially an object
> database that lazily maps in chunks of the data store on demand. The objects
> are then used directly from mapped memory without any intermediate loading
> thanks to some dirty tricks played to guarantee vtbl placement in application
> memory across releases. Ridiculously fast and it allows large databases to be
> used efficiently. This backs an accounting system used by large trading
> firms.

Sorry, I misunderstood.

On Wednesday, 2 October 2013 at 02:30:42 UTC, Walter Bright wrote:

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

That famous prejudice of yours :). As always, it depends. The application can't "recover" but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely.

On Thursday, 3 October 2013 at 08:02:17 UTC, Max Samukha wrote:
> On Wednesday, 2 October 2013 at 02:30:42 UTC, Walter Bright wrote:
>
>> 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.
>
> That famous prejudice of yours :). As always, it depends. The application can't "recover" but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely.

This.

I agree that in a purist sense, a broken program is broken, end of. However, in the real world it's a balance of risk.

On 10/3/2013 1:02 AM, Max Samukha wrote:
> That famous prejudice of yours :).

Not just me, and I didn't invent it. It's a "prejudice" used by experienced engineers who build things that, if they fail, kill people. That prejudice is relearned, over and over, by bitter experience.

> As always, it depends. The application can't
> "recover" but it can give the user an opportunity to (partially) recover his
> work. For example, I appreciated the fact that Cubase/Nuendo often continued
> execution after a poorly debugged in-process plugin segfaulted. I do not know
> exactly what cleanup procedure the application executed on the inconsistent
> state but most of the time I was able to recover it completely.

You've got a badly designed program if it relies on that to recover user data.

On Thursday, 3 October 2013 at 20:54:00 UTC, Walter Bright wrote:
> On 10/3/2013 1:02 AM, Max Samukha wrote:
>> That famous prejudice of yours :).
>
> Not just me, and I didn't invent it. It's a "prejudice" used by experienced engineers who build things that, if they fail, kill people. That prejudice is relearned, over and over, by bitter experience.
>

Music player (as example) do not kill people if they fail.
Aborting whole music player just because Visualisation plugin had access violation is pointless.

You can't put every use case into the same bag...

>> As always, it depends. The application can't
>> "recover" but it can give the user an opportunity to (partially) recover his
>> work. For example, I appreciated the fact that Cubase/Nuendo often continued
>> execution after a poorly debugged in-process plugin segfaulted. I do not know
>> exactly what cleanup procedure the application executed on the inconsistent
>> state but most of the time I was able to recover it completely.
>
> You've got a badly designed program if it relies on that to recover user data.