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

[Mike Meyer]

On Fri, 4 May 2012 14:19:37 -0400
Brandon Allbery <allbery.b at gmail.com> wrote:

> On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <mwm at mired.org> 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,
       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org