Send Beginners mailing list submissions to
beginners@haskell.org
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
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Signals and external bindings... (Edward Z. Yang)
2. Re: Issue installing reactive-banana-5.0.0.1 (Miguel Negrao)
3. Re: Signals and external bindings... (Brandon Allbery)
4. Re: Signals and external bindings... (Antoine Latter)
5. Re: Signals and external bindings... (Brandon Allbery)
6. Re: Signals and external bindings... (Mike Meyer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 04 May 2012 14:12:55 -0400
From: "Edward Z. Yang" <ezy...@mit.edu>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: Mike Meyer <m...@mired.org>
Cc: beginners <beginners@haskell.org>
Message-ID: <1336154962-sup-9615@ezyang>
Content-Type: text/plain; charset=UTF-8
It is a tricky subject, but not insurmountable.
http://blog.ezyang.com/2010/08/interrupting-ghc/
http://www.haskell.org/ghc/docs/7.2.2/html/users_guide/ffi.html#ffi-interruptible
http://blog.ezyang.com/2010/11/its-just-a-longjmp-to-the-left/
Cheers,
Edward
Excerpts from Mike Meyer's message of Wed May 02 13:00:41 -0400 2012:
> I've just finished a QAD project in Python, and expect them to ask
> me to build the production version of the same project. I'd like to
> switch to Haskell, but (again, for those who noticed) have some
> questions I'd like answered.
>
> One problem I ran into is that I use Unix signals to control the
> various processes. In CPython, this causes a problem with extension
> code because the python signal handler at the C level just note the
> signal, then wait to run the Python "signal handler" the next time the
> interpreter. 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.
>
> Since I expect to such extensions (the wrappers are available) and
> want to leave the control mechanisms in place, I'd like to know if I'm
> going to have similar problems in Haskell.
>
> Thanks,
> <mike
------------------------------
Message: 2
Date: Fri, 4 May 2012 19:15:45 +0100
From: Miguel Negrao <miguel.negrao-li...@friendlyvirus.org>
Subject: Re: [Haskell-beginners] Issue installing
reactive-banana-5.0.0.1
To: beginners@haskell.org
Message-ID: <7a36ef86-5828-47a4-b9e9-16c86ec8e...@friendlyvirus.org>
Content-Type: text/plain; charset=windows-1252
Hi,
>> Is any generality lost because of this or are the approaches
>> equivalent ?
>
> Once you have a timer, you can make a behavior
>
> time :: Behavior t Time
>
> that indicates the current time and thus allows you to write functions that
> depend on the current clock time, just like in Conal's papers.
>
> In other words, the approaches are largely equivalent.
>
> The thing is just that different GUI or audio frameworks tend to have
> different implementations of timers and reactive-banana can't decide which
> one is more appropriate. For instance, Henning Thielemann uses ALSA-timers in
> his reactive-balsa package
>
> http://hackage.haskell.org/package/reactive-balsa-0.0
>
> At some point, I intend to offer some common time-related functionality (for
> example as in the Wave.hs example) for different backends.
Ok, I see, yes make sense.
One other question, is it possible in reactive-banana to define ?recursive?
event streams. For instance consider a stream which receives numbers between
0.0 and 1.0. If the last outputted value was between 0.8 an 1.0 then output
1-x otherwise output x. After that it only leta numbers through if they are
between 0.0 and 0.2 or between 0.8 and 1.0.
This looks like:
|
x
V
---------------------------
| y > 0.8 |<--------------y----------------|
| |
|
-------------------------- |
| |
|
| yes | no |
V V
|
1-x x
|
| /
|
V /
|
-------------- |
|
|
|
|
V
|
---------------------------------------------------- |
| select values between 0.0 and 0.2 | |
| and 0 8 and 1.0 | |
| ||
|
---------------------------------------------------- |
|
|
|------------------------------------------------------------
|
y
|
V
best,
Miguel Negr?o
------------------------------
Message: 3
Date: Fri, 4 May 2012 14:19:37 -0400
From: Brandon Allbery <allber...@gmail.com>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: Mike Meyer <m...@mired.org>
Cc: beginners@haskell.org
Message-ID:
<CAKFCL4V+kNwczQC3d=L+=3tj7vec=hrxfpug8pbwfuw2gxm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@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.
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.
2. Registering a Haskell-based signal handler would be a special case of
arranging for C to call into Haskell code (since that is in fact what it
would be doing; the real signal handler is C invoked from an assembler
trampoline). As things currently work, this can only be done from calls to
C which suspend the Haskell runtime in a known safe state; asynchronous
signals don't provide any way to arrange this, any more than they insure
C's malloc() arena is consistent or etc.
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.
--
brandon s allbery allber...@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/b019d623/attachment-0001.htm>
------------------------------
Message: 4
Date: Fri, 4 May 2012 14:55:54 -0500
From: Antoine Latter <aslat...@gmail.com>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: Brandon Allbery <allber...@gmail.com>
Cc: beginners@haskell.org
Message-ID:
<CAKjSnQE5G_UpjJQ4duzn6imp5xA7L3NFh=H8A=fzjs9ieba...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, May 4, 2012 at 1:19 PM, Brandon Allbery <allber...@gmail.com> wrote:
> On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@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.
>
Well, there is this:
http://www.haskell.org/ghc/docs/latest/html/libraries/unix-2.5.1.0/System-Posix-Signals.html#g:4
But it's bit short on what exact semantics it provides. It looks like
it uses this chunk of code on GHC (on Posix systems):
https://github.com/ghc/ghc/blob/376210565e4dff2679246c6ebbcdbb3163c9e8a5/rts/posix/Signals.c
Antoine
------------------------------
Message: 5
Date: Fri, 4 May 2012 16:18:54 -0400
From: Brandon Allbery <allber...@gmail.com>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: Antoine Latter <aslat...@gmail.com>
Cc: beginners@haskell.org
Message-ID:
<CAKFCL4V5N4FQ1gWDyAEky8LUfOV6TogO8Gd-c7-ovULUdwT4=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, May 4, 2012 at 3:55 PM, Antoine Latter <aslat...@gmail.com> wrote:
> On Fri, May 4, 2012 at 1:19 PM, Brandon Allbery <allber...@gmail.com>
> wrote:
> > On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@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
> >
> > 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.
>
> Well, there is this:
>
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/unix-2.5.1.0/System-Posix-Signals.html#g:4
OK, looks like that does what I said in my final paragraph (which was
written based on the runtime Signals.c source).
--
brandon s allbery allber...@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/9fc83db8/attachment-0001.htm>
------------------------------
Message: 6
Date: Fri, 4 May 2012 23:24:12 -0400
From: Mike Meyer <m...@mired.org>
Subject: Re: [Haskell-beginners] Signals and external bindings...
To: beginners@haskell.org <beginners@haskell.org>
Message-ID: <20120504232412.2f0ff...@bhuda.mired.org>
Content-Type: text/plain; charset=UTF-8
On Fri, 4 May 2012 14:19:37 -0400
Brandon Allbery <allber...@gmail.com> wrote:
> On Fri, May 4, 2012 at 1:26 PM, Mike Meyer <m...@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 <m...@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
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 47, Issue 5
****************************************
