On Fri, Sep 16, 2016 at 10:54 AM, Rolf Kvinge via Mono-devel-list <
> > On 16/09/16 19:22, "Miguel de Icaza" <mig...@microsoft.com> wrote:
> > Hello,
> > Thanks for getting these proposals out Rolf.
> > I am not a fan of any of the provided options.
> > We have two issues here: Mono is doing the right thing by supporting
> “chained handlers”, but many of these libraries can not chain signal
> > Let me propose that we add a pair of methods, to undo the signal
> handling setup, and to restore the handling setup and surface those to
> managed code.
> > The code for things like HockeyApp would become:
> > Mono.UndoSignalHandlingSetup (); // SIGSEGV points
> back to original handlers
> > HockeyAppInstallHandlers (); // SIGSEGV now
> points to HockeyApp handlers
> > Mono.InstallSignalHandlers (); // SIGSEGV now
> points to Mono handler, that have chained capabilities
> > The Undo/Install is necessary for the rare case of a library that can do
> proper chaining and might want to chain to another handler, so they would
> not chain back to Mono.
> I think this could work.
> Another advantage is that it would not require any code changes in the
> products, only Mono.
> I can have a look at implementing (and testing) this, unless the runtime
> team wants to do it?
I don't like it. It's racy, it's unsafe and it will be incredibly hard to
troubleshoot when it goes wrong.
If something bad, like an exception, happens during
HockeyAppInstallHandlers the app will hard
crash instead of throwing a NRE and troubleshooting that will be tricky.
In addition to that, that API leaves a window for which all the other
threads in the app
must not poke into a null pointer or they will hard crash.
Mono-devel-list mailing list