Hey Rolf, Looks good. Documentation goes into mono-project.com.
-- Rodrigo On Fri, Sep 23, 2016 at 5:28 AM, Rolf Kvinge via Mono-devel-list < mono-devel-list@lists.dot.net> wrote: > Hi, > > > I've tried implementing this, here's a Mono PR for it: > https://github.com/mono/mono/pull/3624 > > I'm not where to document the new managed API though. > > > Rolf > > > Sent from Outlook <http://aka.ms/weboutlook> > ------------------------------ > *From:* Rodrigo Kumpera > *Sent:* Thursday, September 22, 2016 11:05:07 PM > *To:* Miguel de Icaza; Rolf Kvinge > *Cc:* macios-de...@lists.dot.net; mono-devel-list@lists.dot.net; > android-de...@lists.dot.net > > *Subject:* Re: [android-devel] [macios-devel] Signal-chaining & crash > reporters > > > Hey, > > > > Given Rolf’s constraints, I don’t think we can do reasonably better than > your proposal. > > > > -- > > Rodrigo > > > > > > *From: *Miguel de Icaza <mig...@microsoft.com> > *Date: *Tuesday, September 20, 2016 at 6:01 AM > *To: *Rolf Kvinge <rolf.kvi...@microsoft.com>, Rodrigo Kumpera < > rokum...@microsoft.com> > *Cc: *"macios-de...@lists.dot.net" <macios-de...@lists.dot.net>, " > mono-devel-list@lists.dot.net" <mono-devel-list@lists.dot.net>, " > android-de...@lists.dot.net" <android-de...@lists.dot.net> > *Subject: *Re: [android-devel] [macios-devel] Signal-chaining & crash > reporters > > > > Hello, > > > > My proposal addressed that, the downside is that there is a window at > startup where the runtime will not catch exceptions properly. > > > > I think it is fair to document the limitation of the technique in those > scenarios. > > > > *From: *Rolf Kvinge <rolf.kvi...@microsoft.com> > *Date: *Tuesday, September 20, 2016 at 5:17 AM > *To: *Rodrigo Kumpera <rokum...@microsoft.com> > *Cc: *Miguel de Icaza <mig...@microsoft.com>, "macios-de...@lists.dot.net" > <macios-de...@lists.dot.net>, "mono-devel-list@lists.dot.net" < > mono-devel-list@lists.dot.net>, "android-de...@lists.dot.net" < > android-de...@lists.dot.net> > *Subject: *Re: [android-devel] [macios-devel] Signal-chaining & crash > reporters > > > > > > Hi Rodrigo, > > > > I think we should first decide how we want to expose this in managed code, > since using your idea I don't see any options besides those I initially > proposed (and which Miguel didn't like). > > > > One of the problems is that there's a lot of people involved here: > > > > 1) The native library that detects crashes and collects crash information. > On iOS this is typically PLCrashReporter [1]. > > > > 2) Companies that build native crash reporting solutions on top of > libraries from 1). On iOS this is HockeyApp, Insights, Crittercism, > Flurry (which all use PLCrashReporter I believe), Crashlytics (which is not > using PLCrashReporter, they wrote their own replacement [2]), etc. > > > > 3) The managed bindings for the products in 2). Some of these we maintain > ourselves (in the component store - Crittercism [3]), some are maintained > by those companies themselves (HockeyApp [4]), and some I believe are > community supported/written. > > > > 4) Us. > > > > 5) The app (developer). > > > > Ideally whatever we come up with should require changes from as few of > these as possible, the best case scenario being #3 only (besides ourselves > of course). Any changes to #1 will likely require changes to #2 as well. > > > > Rolf > > > > [1] https://plcrashreporter.org > > [2] http://stackoverflow.com/questions/14041789/comparison- > between-testflight-live-quincykit-and-crashlytics#comment19667280_14103776 > > [3] https://components.xamarin.com/gettingstarted/crittercism > > [4] https://github.com/bitstadium/HockeySDK-Xamarin > > > > Sent from Outlook <http://aka.ms/weboutlook> > ------------------------------ > > *From:* Rodrigo Kumpera > *Sent:* Monday, September 19, 2016 8:51:02 PM > *To:* Rolf Kvinge > *Cc:* Miguel de Icaza; macios-de...@lists.dot.net; > mono-devel-list@lists.dot.net; android-de...@lists.dot.net > *Subject:* Re: [android-devel] [macios-devel] Signal-chaining & crash > reporters > > > > Hey Rolf, > > On your suggestion, I’m not sure that’s exactly what we want. > Even though we can ask user to do signal chaining themselves, I don’t > think it’s necessary. I don’t think we should be promoting the broken > design of posix signals around. ;) > Another thing is that this design is not portable and exposes a bit too > much of mono internals. > > What about this: https://gist.github.com/569e860dd7e73bde0d8d098f95143662 > > It probably won’t compile as I normalized the signature of > mono_handle_native_sigsegv with other similar functions. > > -- > Rodrigo > > > On 9/19/16, 3:25 AM, "Rolf Kvinge" <rolf.kvi...@microsoft.com> wrote: > > > Hi, > > > From: Rodrigo Kumpera > > > > > > 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. > > This is not about exposing signal handlers to managed code, the signal > handlers we want called are always in native code. > > > > > > > > > I guess the simple solution is to add an embedding API call that > queues signal handlers > > to be called first before chaining to the OS one. > > Something like this: https://gist.github.com/rolfbjarne/ > 6aab59c1609f33402d195f9c34e9f99b? > > Rolf > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.dot.net > http://lists.dot.net/mailman/listinfo/mono-devel-list > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.dot.net http://lists.dot.net/mailman/listinfo/mono-devel-list