On 10 April 2006 22:19, John Meacham wrote:
On Fri, Apr 07, 2006 at 02:58:01PM +0100, Simon Marlow wrote:
According to your definition of exitWith above, I can't both raise an
exception *and* exit in the same thread. If I register an onExit
handler that throws an exception to the current
On Tue, Apr 11, 2006 at 08:54:32AM +0100, Simon Marlow wrote:
now If I have a handler registered that throws an exception to the
current thread, what happens? handleLoop is aborted, the exception is
propagated to the top level of the thread, where the top-level exception
handler calls
On Mon, Apr 10, 2006 at 02:19:23PM -0700, John Meacham wrote:
On Mon, Apr 10, 2006 at 02:58:20PM +0100, Simon Marlow wrote:
Suppose I want to do some action with a temporary file:
bracket
newTempFile
(\f - removeTempFile f)
(\f - doSomethingWith f)
Under
On Mon, Apr 10, 2006 at 02:58:20PM +0100, Simon Marlow wrote:
Suppose I want to do some action with a temporary file:
bracket
newTempFile
(\f - removeTempFile f)
(\f - doSomethingWith f)
Under your scheme, this code doesn't get to remove its temporary file on
On 07 April 2006 00:36, Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I agree with your assessment of the problems with interruptible
operations in GHC: that it is impossible to completely block async
exceptions across a computation. We could certainly add a way to
On 06 April 2006 23:20, John Meacham wrote:
I'm not proposing that we ignore signals, just that we should clearly
delimit the platform-specific bits, perhaps by putting signal support
into an addendum.
yeah, I was thinking a separate environment addendum should be in the
report, which
On 07 April 2006 13:24, David Roundy wrote:
The catch to this [no pun intended]
is that when the main thread exits all other threads are silently
terminated, without the chance to clean up...
This is a mistake in GHC, I think. When someone calls exit, or when the
main thread exits, all the
On 07 April 2006 13:58, John Meacham wrote:
all threads keep running while the exit handers are running, all
blockExit would do is grab and release an MVar. exit itself takes
that MVar on starting to get rid of races to exit as well as protect
itsesf from 'blockExit' (but won't ever put the
Simon Marlow [EMAIL PROTECTED] writes:
BTW, I just realised a better way to express block. If block is
supposed to count nesting, then we have a problem that you can still
unblock exceptions even within a block by using sufficient number of
unblocks, so the right way is to give block this
On Fri, Apr 07, 2006 at 02:58:01PM +0100, Simon Marlow wrote:
Of course you could implement some global flag to say that an exit is in
progress, but that implies explicit checking of the flag all over the
place, which is what asynchronous exceptions are designed to avoid.
When *do* we exit,
On Wed, Apr 05, 2006 at 03:41:55PM +0100, Simon Marlow wrote:
I have been giving signals some thought, and resarching what other
languages do, and have a semi-proposal-maybe.
We should be careful here: the Haskell standard has so far remained
platform-independent, and I think it would be
Simon Marlow [EMAIL PROTECTED] writes:
I think it's unnecessary to treat signals in the way you do - you're
assuming that a signal interrupts the current thread and runs a new
computation (the signal handler) on the same stack, completely blocking
the interrupted thread until the signal
On Tue, Apr 04, 2006 at 01:33:39PM +0100, Simon Marlow wrote:
I'm not sure whether asynchronous exceptions should be in Haskell'. I
don't feel entirely comfortable about the interruptible operations
facet of the design, and I'm hoping that STM can clean things up: after
all, STM already gives
On 05 April 2006 12:47, David Roundy wrote:
On Tue, Apr 04, 2006 at 01:33:39PM +0100, Simon Marlow wrote:
The fact that throwTo can interrupt a takeMVar, but can't interrupt a
foreign call, even a concurrent one, is a bit strange. We have this
odd situation in GHC right now where throwTo can
On 05 April 2006 13:38, John Meacham wrote:
On Wed, Apr 05, 2006 at 07:47:08AM -0400, David Roundy wrote:
For me, asynchronous exceptions are the primary reason to use
concurrent Haskell. They're the only way I'm aware of to write a
program that handles signals in Haskell, and it's be a real
Simon Marlow [EMAIL PROTECTED] writes:
I'm not sure whether asynchronous exceptions should be in Haskell'.
I don't feel entirely comfortable about the interruptible operations
facet of the design,
I designed that differently for my language. There is a distinct
synchronous mode where
-- Forwarded by Dominic Steinitz/HEATHROW/BRITISH AIRWAYS/GB on
27/11/2001 09:59 ---
From: Dominic Steinitz on 27/11/2001 08:16
To: uk1o
cc: haskell
bcc:
Subject:Re: Asynchronous Exceptions
Hannah,
I was thinking
On Fri, Nov 23, 2001 at 09:38:35AM -, Simon Marlow wrote:
[...]
However, I agree that sometimes you really want to be able
to do this,
so perhaps we need another form of 'block' which doesn't allow *any*
exceptions to be delivered, for those times when you know
that the time
Hello!
On Fri, Nov 23, 2001 at 09:38:35AM -, Simon Marlow wrote:
[...]
However, I agree that sometimes you really want to be able to do this,
so perhaps we need another form of 'block' which doesn't allow *any*
exceptions to be delivered, for those times when you know that the time
Can someone help me understand how this works? I've been
reading the paper Asynchronous Exceptions in Haskell. This
gives a combinator
finally :: IO a - IO b - IO s
finally a b =
block (do {
r - catch (unblock a) (\e - do { b; throw e });
b;
return r; })
20 matches
Mail list logo
