On Thu, May 3, 2012 at 11:48 AM, umptious <umptious@gmail.com> wrote:
On 2 May 2012 19:29, Mike Meyer <mwm@mired.org> wrote:
On Wed, 2 May 2012 13:46:39 -0400
Brandon Allbery <allbery.b@gmail.com> wrote:

> On Wed, May 2, 2012 at 1:00 PM, Mike Meyer <mwm@mired.org> wrote:
> You can use wrappers which save the old signal handlers and install new
> ones which clean up after your plugins and return.  Doing so, and thereby
> learning the hard way what "clean up after your plugins" entails (unless
> you were very careful designing and writing them in the first place), will
> teach you why nobody tries to automatically handle it for you.  (In the
> general case, your plugin has to track *everything* so it can unwind (or
> commit, as appropriate) memory and resource allocations on signal.)

So unless I'm using something like Qt which can catch the signals and
run it's own code to call back to my code and then shut itself down,
I'm pretty much SOL.

What would happen if there was a Haskell process that ran as a dispatcher/telephone exchange? If this received a message from a C process and then sent the signal, wouldn't this work?

What problem do you think this is solving?  Because it isn't solving the problem with the Haskell runtime being unable to clean up the internal state of arbitrary C code, which is the reason C code is run the way it is by most other environments.

--
brandon s allbery                                      allbery.b@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms