Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Understanding "Signals, Not Generators" (Nathan H?sken)
2. Re: Signals and external bindings... (umptious)
3. Re: Signals and external bindings... (Brandon Allbery)
4. Re: Signals and external bindings... (Mike Meyer)
5. Re: Signals and external bindings... (Mike Meyer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 04 May 2012 16:18:30 +0200
From: Nathan H?sken <[email protected]>
Subject: [Haskell-beginners] Understanding "Signals, Not Generators"
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hey
I am currently reading Signals, Not Generators". I am on page 10 where the
phantom type era is introduced. I have trouble understanding because I do not
understand how the system is to be used. Let us assume I have a signal and an
action to print the output:
signal :: DSignal era Int
action :: Int -> Io ()
action = putStrLn . show
Now, I consume the signal:
reactive = consume signal action
=> reactive :: Reactive era (IO ())
And make an io action:
toIO reactive :: IO ()
My question is: what does this io action do?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120504/191026ec/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 4 May 2012 17:23:36 +0100
From: umptious <[email protected]>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: Brandon Allbery <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID:
<cae20bnuczrd2kmnfhokhfbarzqi8kvfq2jv2w7of9obzrnu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
>
>> 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.
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?
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120504/d81ab485/attachment-0001.htm>
------------------------------
Message: 3
Date: Fri, 4 May 2012 12:54:00 -0400
From: Brandon Allbery <[email protected]>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: umptious <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID:
<cakfcl4vq4x+p+e55l3hkh8i9f5dotkuzueohbasudvvwvdt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, May 4, 2012 at 12:23 PM, umptious <[email protected]> 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 [email protected]
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-0001.htm>
------------------------------
Message: 4
Date: Fri, 4 May 2012 13:14:21 -0400
From: Mike Meyer <[email protected]>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
On Fri, 4 May 2012 17:23:36 +0100
umptious <[email protected]> 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 <[email protected]> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
------------------------------
Message: 5
Date: Fri, 4 May 2012 13:26:44 -0400
From: Mike Meyer <[email protected]>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
On Fri, 4 May 2012 12:54:00 -0400
Brandon Allbery <[email protected]> wrote:
> What the OP wants is for a signal to abort the C function and return
> control to the Haskell or Python runtime.
Not quite. What I want is for my code in Haskell or Python to run when
the signal arrives (basically, on the signal handler), as opposed to
waiting until the C code returns control to the Haskell or Python
runtime But that's just the first step.
> Do you understand why this requires arbitrary cleanup capability to
> be safe?
Well, it's clear to me that what I want to do requires arbitrary
cleanup capabilities. If the C library doesn't provide a mechanism to
shut itself down cleanly, nothing will work.
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?
Thanks,
<mike
--
Mike Meyer <[email protected]> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 47, Issue 4
****************************************
