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

[Mike Meyer]

On Fri, 4 May 2012 17:23:36 +0100
umptious <umptious at gmail.com> wrote:

> >> 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.
> Well the OP wrote
> >> Since my extensions are doing the heavy lifting, they
> often run for long periods (by which I mean 10s of minutes). Meaning
> the signal is ignored for long periods.<<
> and you responded
> >> Cross-runtime borders are *always* a problem for signals and various
> resources that may need to be cleaned up. <<
> So if both statements are true and non-misleading, a solution with a
> dispatcher thread to catch messages would avoid this problem. Because there
> would be no cross-runtime border for signals. And the dispatcher thread
> could respond to messages immediately with "I'm taking responsibility for
> this message now" possibily simplifying the C code.

My (aka the OP) problem isn't with signals per se, it's with shutting
down the C code cleanly. The way things are handled in the current
implementation does pretty much what I understand you to be saying here:

The runtime catches the signal. Since it was jumped into from the C
code, it can't really do anything about it, so it notes it for the
next time it's actually in control (which is how I read your "then
sent the signal"). The problem is that the C code may run for minutes
before that happens.

> Or the C code has to send signals, then wouldn't it be possible for a
> dispatcher thread to catch them, and wouldn't that simplify architecture?

No, that doesn't help.  I'm not got threads now, so why add another
problem?  In any case, now the dispatcher thread catches the signal
while waiting "in the runtime" and can process it immediately, but
it's still got to deal with shutting down the thread running the C
code.

Either way, unless the C code provides some way to say "stop this",
you're SOL. And that may not be enough. If you're running in a signal
handler triggered while running the C code, you have to follow
whatever rules *it* has for doing so. In my case that was "you can't
call any of our methods in a signal handler."

> >>> 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.
> Well, NOTHING Haskell could do could clean up after literally arbitrary C
> code! But was the OP asking that question? It would seem a rather strange
> one. I thought the problem was that additional complexity was being added
> to said clean-up was coming from the very long time required to respond to
> signals, and the OP was asking if there was anyway to avoid this - which is
> a very different question.

Actually, the question I was trying to ask is:

"Will my Haskell signal handlers get run when the signal arrives, or
do I have to wait for the C code to return control to Haskell for them
to run?" I think the answer is "I have to wait".

The way I beat the problem in the current code was to add a timer to
the C code that does nothing every second - but does via a callback to
my runtime. That's when my signal handler will get run. Since that's
not running in the actual signal handler (which just notes the signal
for when control returns to my runtime), that can use the methods the
C library provides to stop it cleanly.

It works. It's ugly. It's very touchy about code changes. It was a
pain to figure out. But it does work.

      <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