Hey guys,

Exposing signal handlers from managed code is always the wrong solution.

If we're crashing in the runtime, a managed code signal handler has very little 
chance of works. It's a scenario we will never even consider supporting.

I guess the simple solution is to add an embedding API call that queues signal 
to be called first before chaining to the OS one.


Sent from Nylas 
 the extensible, open source mail client.

On Sep 16 2016, at 12:00 pm, Rolf Kvinge via android-devel 
<android-de...@lists.dot.net> wrote:


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


macios-devel mailing list

android-devel mailing list
Mono-devel-list mailing list

Reply via email to