#3997: Lazy I/O and asynchronous exceptions don't mix well
--+-
Reporter: simonmar | Owner:
Type: bug | Status: closed
the exception in a different thread instead.
You have complete control over which asynchronous exceptions are thrown
to a thread. You might argue that StackOverflow/HeapOverflow aren't
under your control - but in fact StackOverflow will never be raised
inside mask. If/when we ever implement HeapOverflow
Hi!
On Thu, Dec 16, 2010 at 10:30 AM, Simon Marlow marlo...@gmail.com wrote:
I've thought about whether we could support resumption in the past. It's
extremely difficult to implement - imagine if the thread was in the middle
of an I/O operation - should the entire I/O operation be restarted
the exception in a different thread instead.
You have complete control over which asynchronous exceptions are thrown
to a thread. You might argue that StackOverflow/HeapOverflow aren't
under your control - but in fact StackOverflow will never be raised
inside mask. If/when we ever implement HeapOverflow
Hi!
On Thu, Dec 16, 2010 at 10:30 AM, Simon Marlow marlo...@gmail.com wrote:
I've thought about whether we could support resumption in the past. It's
extremely difficult to implement - imagine if the thread was in the middle
of an I/O operation - should the entire I/O operation be restarted
On 17/12/2010, at 12:03 PM, Mitar wrote:
Yes, this is the same problem as when designing an operating system:
what should happen to a system call if it is interrupted. And I agree
with elegance of simply returning EINTR errno. This makes system calls
much easier to implement and for user it
Hi!
On Wed, Dec 1, 2010 at 10:50 AM, Simon Marlow marlo...@gmail.com wrote:
Yes, but semantics are different. I want to tolerate some exception
because they are saying I should do this and this (for example user
interrupt, or timeout) but I do not want others, which somebody else
maybe
Hi!
On Wed, Dec 1, 2010 at 10:50 AM, Simon Marlow marlo...@gmail.com wrote:
Yes, but semantics are different. I want to tolerate some exception
because they are saying I should do this and this (for example user
interrupt, or timeout) but I do not want others, which somebody else
maybe
to the Control.Exception documentation, in
the section on Interruptible operations. Suggestions for improvements
are welcome:
It is useful to think of 'mask' not as a way to completely prevent
asynchronous exceptions, but as a filter that allows them to be raised
only at certain places
On 01/12/2010 03:02, Mitar wrote:
Hi!
On Thu, Nov 18, 2010 at 2:19 PM, Simon Marlowmarlo...@gmail.com wrote:
then it isn't uninterruptible, because the timeout can interrupt it. If you
can tolerate a timeout exception, then you can tolerate other kinds of async
exception too.
Yes, but
On 01/12/2010 03:02, Mitar wrote:
Hi!
On Thu, Nov 18, 2010 at 2:19 PM, Simon Marlowmarlo...@gmail.com wrote:
then it isn't uninterruptible, because the timeout can interrupt it. If you
can tolerate a timeout exception, then you can tolerate other kinds of async
exception too.
Yes, but
Hi!
On Thu, Nov 18, 2010 at 2:19 PM, Simon Marlow marlo...@gmail.com wrote:
then it isn't uninterruptible, because the timeout can interrupt it. If you
can tolerate a timeout exception, then you can tolerate other kinds of async
exception too.
Yes, but semantics are different. I want to
Hi!
On Thu, Nov 18, 2010 at 2:19 PM, Simon Marlow marlo...@gmail.com wrote:
then it isn't uninterruptible, because the timeout can interrupt it. If you
can tolerate a timeout exception, then you can tolerate other kinds of async
exception too.
Yes, but semantics are different. I want to
Hi!
On Wed, Nov 17, 2010 at 12:00 PM, Simon Marlow marlo...@gmail.com wrote:
That's hard to do, because the runtime system has no knowledge of exception
types, and I'm not sure I like the idea of baking that knowledge into the
RTS.
But currently it does have a knowledge of interruptible and
On 18/11/2010 11:31, Mitar wrote:
Hi!
On Wed, Nov 17, 2010 at 12:00 PM, Simon Marlowmarlo...@gmail.com wrote:
That's hard to do, because the runtime system has no knowledge of exception
types, and I'm not sure I like the idea of baking that knowledge into the
RTS.
But currently it does have
Hi!
On Wed, Nov 17, 2010 at 12:00 PM, Simon Marlow marlo...@gmail.com wrote:
That's hard to do, because the runtime system has no knowledge of exception
types, and I'm not sure I like the idea of baking that knowledge into the
RTS.
But currently it does have a knowledge of interruptible and
On 18/11/2010 11:31, Mitar wrote:
Hi!
On Wed, Nov 17, 2010 at 12:00 PM, Simon Marlowmarlo...@gmail.com wrote:
That's hard to do, because the runtime system has no knowledge of exception
types, and I'm not sure I like the idea of baking that knowledge into the
RTS.
But currently it does have
#4400: Asynchronous exceptions in runInUnboundThread
-+--
Reporter: basvandijk | Owner: simonmar
Type: proposal| Status: closed
Priority: high
On 12/11/2010 07:49, Mitar wrote:
On Wed, Nov 10, 2010 at 4:48 PM, Simon Marlowmarlo...@gmail.com wrote:
You can use maskUninterruptible in GHC 7, but that is not generally
recommended,
Maybe there should be some function like maskUninterruptibleExceptUser
which would mask everything except
On 12/11/2010 07:49, Mitar wrote:
On Wed, Nov 10, 2010 at 4:48 PM, Simon Marlowmarlo...@gmail.com wrote:
You can use maskUninterruptible in GHC 7, but that is not generally
recommended,
Maybe there should be some function like maskUninterruptibleExceptUser
which would mask everything except
On Wed, Nov 10, 2010 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote:
[...] So we should
say there are a few things that you can do that guarantee not to call any
interruptible operations:
- IORef operations
- STM transactions that do not use retry
- everything from the Foreign.*
On Wed, Nov 10, 2010 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote:
[...] So we should
say there are a few things that you can do that guarantee not to call any
interruptible operations:
- IORef operations
- STM transactions that do not use retry
- everything from the Foreign.*
On 10/11/2010 17:52, Mitar wrote:
Hi!
On Wed, Nov 10, 2010 at 4:16 PM, Simon Marlowmarlo...@gmail.com wrote:
The right way to fix it is like this:
Optimist. ;-)
let run = unblock doSomething `catches` [
Handler (\(_ :: MyTerminateException) - return ()),
Hi!
On Wed, Nov 10, 2010 at 4:48 PM, Simon Marlow marlo...@gmail.com wrote:
You can use maskUninterruptible in GHC 7, but that is not generally
recommended,
Maybe there should be some function like maskUninterruptibleExceptUser
which would mask everything except UserInterrupt exception. Or
On 10/11/2010 17:52, Mitar wrote:
Hi!
On Wed, Nov 10, 2010 at 4:16 PM, Simon Marlowmarlo...@gmail.com wrote:
The right way to fix it is like this:
Optimist. ;-)
let run = unblock doSomething `catches` [
Handler (\(_ :: MyTerminateException) - return ()),
Hi!
On Wed, Nov 10, 2010 at 4:48 PM, Simon Marlow marlo...@gmail.com wrote:
You can use maskUninterruptible in GHC 7, but that is not generally
recommended,
Maybe there should be some function like maskUninterruptibleExceptUser
which would mask everything except UserInterrupt exception. Or
#1036: Asynchronous exceptions improvements
-+--
Reporter: simonmar| Owner: simonmar
Type: task| Status: closed
Priority: normal
#1036: Asynchronous exceptions improvements
-+--
Reporter: simonmar| Owner: simonmar
Type: task| Status: closed
Priority: normal
to catch it so it will be reported.
Finally, your code has dangerous deadlock potential: Because you don't
mask asynchronous exceptions before you fork it could be the case that
an asynchronous exception is thrown to the thread before your
exception handler is registered. This will cause the thread
Hi!
On Wed, Nov 10, 2010 at 8:54 AM, Bas van Dijk v.dijk@gmail.com wrote:
A ThreadKilled exception is not printed to stderr because it's not
really an error and should not be reported as such.
So, how to make custom exceptions which are not really an error?
What do you mean by hanging
asynchronous exceptions before you fork it could be the case that
an asynchronous exception is thrown to the thread before your
exception handler is registered. This will cause the thread to abort
without running your finalizer: 'putMVar terminated ()'. Your
'takeMVar terminated' will then deadlock
On Wed, Nov 10, 2010 at 2:39 PM, Mitar mmi...@gmail.com wrote:
Strange. It would help if you could show more of of your code.
I am attaching a sample program which shows this. I am using 6.12.3 on
both Linux and Mac OS X. And I run this program with runhaskell
Test.hs. Without throwIO
On 10/11/2010 14:32, Bas van Dijk wrote:
On Wed, Nov 10, 2010 at 2:39 PM, Mitarmmi...@gmail.com wrote:
Strange. It would help if you could show more of of your code.
I am attaching a sample program which shows this. I am using 6.12.3 on
both Linux and Mac OS X. And I run this program with
), the
following things can raise asynchronous exceptions:
- interruptible operations (MVar operations, throwTo, atomically)
Since we can't be certain that an IO operation from a library does not
invoke any interruptible operations, we have to assume that all IO
functions from libraries can raise
Hi!
On Wed, Nov 10, 2010 at 4:16 PM, Simon Marlow marlo...@gmail.com wrote:
The right way to fix it is like this:
Optimist. ;-)
let run = unblock doSomething `catches` [
Handler (\(_ :: MyTerminateException) - return ()),
Handler (\(e :: SomeException) -
to catch it so it will be reported.
Finally, your code has dangerous deadlock potential: Because you don't
mask asynchronous exceptions before you fork it could be the case that
an asynchronous exception is thrown to the thread before your
exception handler is registered. This will cause the thread
Hi!
On Wed, Nov 10, 2010 at 8:54 AM, Bas van Dijk v.dijk@gmail.com wrote:
A ThreadKilled exception is not printed to stderr because it's not
really an error and should not be reported as such.
So, how to make custom exceptions which are not really an error?
What do you mean by hanging
asynchronous exceptions before you fork it could be the case that
an asynchronous exception is thrown to the thread before your
exception handler is registered. This will cause the thread to abort
without running your finalizer: 'putMVar terminated ()'. Your
'takeMVar terminated' will then deadlock
On Wed, Nov 10, 2010 at 2:39 PM, Mitar mmi...@gmail.com wrote:
Strange. It would help if you could show more of of your code.
I am attaching a sample program which shows this. I am using 6.12.3 on
both Linux and Mac OS X. And I run this program with runhaskell
Test.hs. Without throwIO
On 10/11/2010 14:32, Bas van Dijk wrote:
On Wed, Nov 10, 2010 at 2:39 PM, Mitarmmi...@gmail.com wrote:
Strange. It would help if you could show more of of your code.
I am attaching a sample program which shows this. I am using 6.12.3 on
both Linux and Mac OS X. And I run this program with
), the
following things can raise asynchronous exceptions:
- interruptible operations (MVar operations, throwTo, atomically)
Since we can't be certain that an IO operation from a library does not
invoke any interruptible operations, we have to assume that all IO
functions from libraries can raise
Hi!
On Wed, Nov 10, 2010 at 4:16 PM, Simon Marlow marlo...@gmail.com wrote:
The right way to fix it is like this:
Optimist. ;-)
let run = unblock doSomething `catches` [
Handler (\(_ :: MyTerminateException) - return ()),
Handler (\(e :: SomeException) -
Hi!
I have been spend some time to debug this in my program. ;-)
Why is ThreadKilled not displayed by RTS when send to thread (and
unhandled), but any other exception is?
For example, I am using custom exceptions to signal different kinds of
thread killing. Based on those my threads cleanup in
On Tue, Nov 9, 2010 at 5:37 PM, Mitar mmi...@gmail.com wrote:
Why is ThreadKilled not displayed by RTS when send to thread (and
unhandled), but any other exception is?
A ThreadKilled exception is not printed to stderr because it's not
really an error and should not be reported as such. It is
Hi!
I have been spend some time to debug this in my program. ;-)
Why is ThreadKilled not displayed by RTS when send to thread (and
unhandled), but any other exception is?
For example, I am using custom exceptions to signal different kinds of
thread killing. Based on those my threads cleanup in
On Tue, Nov 9, 2010 at 5:37 PM, Mitar mmi...@gmail.com wrote:
Why is ThreadKilled not displayed by RTS when send to thread (and
unhandled), but any other exception is?
A ThreadKilled exception is not printed to stderr because it's not
really an error and should not be reported as such. It is
#1036: Asynchronous exceptions improvements
-+--
Reporter: simonmar| Owner: simonmar
Type: task| Status: closed
Priority: normal
#4400: Asynchronous exceptions in runInUnboundThread
-+--
Reporter: basvandijk|Owner: simonmar
Type: proposal | Status: patch
Priority: high
#1036: Asynchronous exceptions improvements
-+--
Reporter: simonmar| Owner: simonmar
Type: task| Status: closed
Priority: normal
#1036: Asynchronous exceptions improvements
-+--
Reporter: simonmar| Owner: simonmar
Type: task| Status: closed
Priority: normal
#4400: Asynchronous exceptions in runInUnboundThread
-+--
Reporter: basvandijk| Owner:
Type: proposal | Status: patch
Priority: normal
#4400: Asynchronous exceptions in runInUnboundThread
-+--
Reporter: basvandijk| Owner:
Type: proposal | Status: new
Priority: normal
#4400: Asynchronous exceptions in runInUnboundThread
-+--
Reporter: basvandijk| Owner:
Type: proposal | Status: new
Priority: normal
#3944: Asynchronous exceptions and laziness bugs (with fixes) in
Control.Concurrent.QSem/QSemN
-+--
Reporter: basvandijk | Owner: simonmar
Type: bug | Status: closed
#1036: Asynchronous exceptions improvements
-+--
Reporter: simonmar| Owner: simonmar
Type: task| Status: closed
Priority: normal
#3944: Asynchronous exceptions and laziness bugs (with fixes) in
Control.Concurrent.QSem/QSemN
-+--
Reporter: basvandijk|Owner: simonmar
Type: bug | Status: patch
#3944: Asynchronous exceptions and laziness bugs (with fixes) in
Control.Concurrent.QSem/QSemN
-+--
Reporter: basvandijk|Owner:
Type: bug | Status: patch
#3997: Lazy I/O and asynchronous exceptions don't mix well
--+-
Reporter: simonmar | Owner:
Type: bug | Status: closed
#3997: Lazy I/O and asynchronous exceptions don't mix well
-+--
Reporter: simonmar |Owner:
Type: bug | Status: new
I couldn't find any information on whether catchSTM catches
asynchronous exceptions
so I tried to run the following:
import Control.Concurrent.STM
import Control.Concurrent
import Control.Exception
import Prelude hiding (catch)
test = do
tid - myThreadId
forkIO (threadDelay 500
that an asynchronous exception could be raised in this
thread after openFile executes but *before* the appropriate handlers are
installed and the operation is run, preventing hClose from executing?
If 'bracket' does not handle this case, should I be using the
block/unblock functions to disable asynchronous
this case, should I be using the block/unblock
functions to disable asynchronous exceptions:
block
(bracket
(openFile filename ReadMode)
(hClose)
(\fileHandle - do
unblock
({ ... })))
Does this answer your question?
http://haskell.org/ghc/docs/latest/html
be raised in this thread
after openFile executes but *before* the appropriate handlers are installed
and the operation is run, preventing hClose from executing?
If 'bracket' does not handle this case, should I be using the block/unblock
functions to disable asynchronous exceptions:
block
(bracket
Yang wrote:
To follow up on my previous post (Asynchronous Exceptions and the
RealWorld), I've decided to put together something more concrete in
the hopes of eliciting response.
I'm trying to write a library of higher-level concurrency
abstractions, in particular for asynchronous systems
oleg-at-pobox.com |haskell-cafe| wrote:
Yang wrote:
(Something like this is straightforward to build if I abandon
Concurrent Haskell and use cooperative threading, and if the
operations I wanted to perform could be done asynchronously.)
All operations could be done asynchronously, at least on
Yang wrote:
Furthermore, is there any way to embed this information [about async
execptions] in the type system, so that Haskellers don't produce
async-exception-unaware code? (Effectively, introducing checked
interrupts?)
Yes, it is possible to make the information about exceptions and
On 2007-11-16, Yang [EMAIL PROTECTED] wrote (quoting a paper):
This style of concurrency is, of course, not new. Component
architectures where data flows through components (rather than
control) have been called 'actor-oriented' [35]. These can take many
forms. Unix pipes resemble PN, although
- I want to set timeouts on various IO operations in an existing
library, ftphs. However, even if I wrap every call in `block`, it's
unclear whether ftphs has been coded to deal with asynchronous
exceptions, or whether state could be rendered inconsistent. Is there
any solution for this aside
To follow up on my previous post (Asynchronous Exceptions and the
RealWorld), I've decided to put together something more concrete in
the hopes of eliciting response.
I'm trying to write a library of higher-level concurrency
abstractions, in particular for asynchronous systems programming
From the discussion of Help needed interrupting accepting a network
connection, what we have so far is:
* To break out of an accept call, an asynchronous exception is needed.
* The presence of asynchronous exceptions complicates the other code
used to report if accept completed
is:
* To break out of an accept call, an asynchronous exception is needed.
* The presence of asynchronous exceptions complicates the other code
used to report if accept completed or was interrupted, whether
that code is written using MVar's or STM.
Thus the next question
-- for sure?
Then it would be easy to program with MVar's in the presence of
asynchronous exceptions. When you caught an asynchronous exception,
you could set a flag, and then redo the putMVar.
If you call that easy then sure.
For STM, is atomically an interruptible operation? If it is, what
Cat Dancer wrote:
On 12/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote:
Making small programs to test these properties is a good sanity
check. For
instance I just leaned that safePoint = unblock ( return () ) does
not work.
Maybe if you do something to allocate some memory inside of the
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
arbitrary
exceptions thrown by calls to library functions. Asynchronous
exceptions thrown by interruptible operations just fall into this
category.
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
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
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, in fact? When all the exit handlers have finished?
Exceptions are the right way to handle releasing resources, and they
are the right way
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
delayed
indefinitely, unless the target thread remains inside a block. Just
like the fairness property for MVars.
I think this is fine. There's no need for strong guarantees that
asynchronous exceptions are delivered soon or interrrupt any
particular external function calls, or even interrupt
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
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 you a much nicer way to program in an
exception-safe way, as long
Hi all, is there a way, or is it planned to, or has anyone published
articles on... resuming from asynchronous exceptions?
I mean: it would be useful there was a
suspend :: ThreadID - IO ()
where the result is the remaining computation of the other thread, wich
one could forkIO again
For Concurrent Haskell, with respect to asynchronous
exceptions, can a
thread receive an asynchronous exception if it's evaluating
an expression
that could potentially block on IO when evaluated within
the block
function?
Specifically, is interruptibility determined statically
-- 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; })
Now suppose we
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
97 matches
Mail list logo
