
On Thu, May 3, 2012 at 11:48 AM, umptious
On 2 May 2012 19:29, Mike Meyer
wrote: On Wed, 2 May 2012 13:46:39 -0400 Brandon Allbery
wrote: On Wed, May 2, 2012 at 1:00 PM, Mike Meyer
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