Re: [Haskell-beginners] Signals and external bindings...

On Fri, 4 May 2012 14:19:37 -0400 Brandon Allbery wrote:

On Fri, May 4, 2012 at 1:26 PM, Mike Meyer wrote:

...

But I realized I never got a more fundamental question answered: when does a signal handler written in Haskell run? Is it like C, in that it runs when the signal arrives, even if I'm currently executing some wrapped C code, and I have to deal with funky rules about what it can do? Or is it like Python, and it will run the first time the Haskell runtime gets control after the signal arrives? I'm not sure it *does* run. That is, I don't think a Haskell-based signal handler is even possible. When I talk about Haskell's signal handlers, I mean C handlers within the GHC runtime.

Ok, now we're just having vocabulary issues. "Signal handler" is used to mean two different things: 1) Code that runs in the context provided by the OS for handling the signal. As you say, this is typically written in C, and has a bunch of restrictions on what it can and cannot do. 2) Code that someone writes to be run in response to a signal from the OS. In C (and presumably C# and C++), the two are identical. The restrictions may well cause you to write handler-1 code that will be set an notice of some kind to run code in your main context when it's convenient. The latter is technically handler-2 code, but calling such a signal handler isn't common.

1. The GHC runtime only protects garbage collection from signals, it doesn't protect anything else. In particular, unless memory allocation is somehow atomic, a signal arriving while something is doing an allocation dare not itself do any allocation — which means it can do very nearly nothing.

I have to wonder how the boehm gc handles such things?

If a Haskell-hosted signal handler mechanism were to be provided, it would have to be done by invoking the handler from the next run of the event loop. The existing signal handlers work this way already, as I mentioned already; the actual signal handler writes a byte doen a pipe, and the runtime acts on it from its event loop. This is because there is so little that is safe to do from any signal handler, and even less that is safe within the context of GHC's runtime.

Well, one is provided, and implemented as you describe. Given a non-trivial runtime for the language, it seems you either have to do that, or provide a handler-1 environment with so many restrictions that you can't do anything useful, or write a handler-1 that runs the handler-2 once the runtime becomes available again. I guess my question was "which of those two does haskell do", and the answer is the latter. The languages that do the latter all seem to mask the fact that you're writing handler-2 code: the API is similar to the OS API, and the handler-1 code is pretty much invisible. Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org