On Wed, Sep 22, 2010 at 3:18 AM, Mitar mmi...@gmail.com wrote:
What would I also like to see in Haskell is that it would be somehow
possible to see which all exceptions could your function (through used
functions there) throw. In this way it would be really possible to
make
On 22/09/2010 02:18, Mitar wrote:
Hi!
On Tue, Sep 21, 2010 at 11:10 PM, Simon Marlowmarlo...@gmail.com wrote:
So rather than admitting defeat here I'd like to see it become the norm to
write async-exception-safe code.
This is also what I think. You have to make your code work with
Hi!
On Wed, Sep 22, 2010 at 10:21 AM, Simon Marlow marlo...@gmail.com wrote:
You could use maskUninterruptible, but that's not a good solution either - if
an
operation during cleanup really does block, you'd like to be able to
Control-C your
way out.
So maybe this shows a need for
On 22/09/2010 09:51, Mitar wrote:
Hi!
On Wed, Sep 22, 2010 at 10:21 AM, Simon Marlowmarlo...@gmail.com wrote:
You could use maskUninterruptible, but that's not a good solution either - if
an
operation during cleanup really does block, you'd like to be able to Control-C
your
way out.
So
On 14/09/10 19:29, Bryan O'Sullivan wrote:
On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang ezy...@mit.edu
mailto:ezy...@mit.edu wrote:
Pure code can always be safely asynchronously interrupted (even code
using state like the ST monad), and IO code can be made to interact
correctly
Hi!
On Tue, Sep 21, 2010 at 11:10 PM, Simon Marlow marlo...@gmail.com wrote:
So rather than admitting defeat here I'd like to see it become the norm to
write async-exception-safe code.
This is also what I think. You have to make your code work with
exceptions, because they will come sooner or
Excerpts from Ertugrul Soeylemez's message of Mon Sep 13 03:03:11 -0400 2010:
In general it's better to avoid using killThread. There are much
cleaner ways to tell a thread to exit.
This advice doesn't really apply to Haskell: in fact, the GHC developers
have thought really carefully about
On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang ezy...@mit.edu wrote:
Pure code can always be safely asynchronously interrupted (even code
using state like the ST monad), and IO code can be made to interact
correctly with thread termination simply by using appropriate bracketing
functions
Ertugrul's advice is still correct. I'd wager there are very few concurrent
applications that could survive a killThread without disaster. People simply
don't write or test code with that in mind, and even when they do, it's more
likely than not to be wrong.
Does this apply to pure code? I
Bryan O'Sullivan b...@serpentine.com writes:
On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang ezy...@mit.edu wrote:
Pure code can always be safely asynchronously interrupted (even code
using state like the ST monad), and IO code can be made to interact
correctly with thread
On Tue, Sep 14, 2010 at 12:04 PM, Gregory Collins
g...@gregorycollins.netwrote:
That's surprising to me -- this is how we kill the Snap webserver
(killThread the controlling thread...).
It's one thing to design code to work that way and test it all the time, but
it would be quite another to
Hi!
On Tue, Sep 14, 2010 at 9:04 PM, Gregory Collins
g...@gregorycollins.net wrote:
That's surprising to me -- this is how we kill the Snap webserver
(killThread the controlling thread...).
Yes. This does work. The only problem is that my main thread then
kills child threads, which then start
On Tue, Sep 14, 2010 at 9:44 PM, Mitar mmi...@gmail.com wrote:
Hi!
On Tue, Sep 14, 2010 at 9:04 PM, Gregory Collins
g...@gregorycollins.net wrote:
That's surprising to me -- this is how we kill the Snap webserver
(killThread the controlling thread...).
Yes. This does work. The only problem
Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Ertugrul Soeylemez's message of Mon Sep 13 03:03:11 -0400 2010:
In general it's better to avoid using killThread. There are much
cleaner ways to tell a thread to exit.
This advice doesn't really apply to Haskell: in fact, the GHC
Hi!
On Wed, Sep 15, 2010 at 2:16 AM, Ertugrul Soeylemez e...@ertes.de wrote:
The point is that killThread throws an exception. An exception is
usually an error condition.
This is reasoning based on nomenclature. If exceptions were named
Signal or Interrupt?
My approach strictly separates an
On Tue, Sep 14, 2010 at 11:29 AM, Bryan O'Sullivan b...@serpentine.comwrote:
On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang ezy...@mit.edu wrote:
Pure code can always be safely asynchronously interrupted (even code
using state like the ST monad), and IO code can be made to interact
Mitar mmi...@gmail.com wrote:
On Wed, Sep 15, 2010 at 2:16 AM, Ertugrul Soeylemez e...@ertes.de wrote:
The point is that killThread throws an exception. An exception is
usually an error condition.
This is reasoning based on nomenclature. If exceptions were named
Signal or Interrupt?
Mitar mmi...@gmail.com wrote:
I run multiple threads where I would like that exception from any of
them (and main) propagate to others but at the same time that they can
gracefully cleanup after themselves (even if this means not exiting).
I have this code to try, but cleanup functions (stop)
18 matches
Mail list logo
