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

[Brandon Allbery]

On Fri, May 4, 2012 at 12:23 PM, 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.
>

This is about OS signals, not some kind of routable or controllable
messages.  Your options are ignore, die, or a *single* signal handler which
can only safely do a limited number of things.

In any case, the OP is looking for some kind of unwind-on-signal capability
so that receipt of a signal safely aborts the C function in such a way that
the Haskell or Python runtime can resume and neither memory nor resources
(unclear what the hooks are doing but conceivably they could be working
with files etc.) will be leaked.  In practice, when a signal arrives you
can't guarantee much of anything, and specifically in particular neither
malloc() nor stdio are guaranteed to be consistent; if you want to recover
cleanly, you can only set a flag that the main flow of execution checks
regularly (or some morally equivalent mechanism; event-driven systems,
including GHC's own runtime, generally write a byte down a designated pipe
which is then handled by the standard event loop).

There just isn't a good way to deal with this otherwise even in an all-C
system; when you're mixing disparate runtimes, it's close to impossible to
handle it sanely.

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.
>

Only a different question if you don't have any idea what's going on...

The OP specifically noted that signals are blocked during cross-calls from
Python and asked if the same is true of Haskell; the answer is yes, and
also for most other runtimes.  I explained *why* they are blocked.  What
the OP wants is for a signal to abort the C function and return control to
the Haskell or Python runtime.  Do you understand why this requires
arbitrary cleanup capability to be safe?

(Hrm; do you understand that C doesn't have garbage collection or even
reference counting, but is entirely manual resource management?  I didn't
explicitly say that, although what I did say should have implied it.)

-- 
brandon s allbery                                      allbery.b at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20120504/0eaaa55c/attachment.htm>