On 25/03/10 17:16, Bas van Dijk wrote:
On Thu, Mar 25, 2010 at 5:36 PM, Simon Marlow<marlo...@gmail.com> wrote:
Nice, I hadn't noticed that you can now code this up in the library since we
added 'blocked'. Unfortunately this isn't cheap: 'blocked' is currently an
out-of-line call to the RTS, so if we want to start using it for important
things like finally and bracket, then we should put some effort into
optimising it.
I'd also be amenable to having block/unblock count nesting levels instead, I
don't think it would be too hard to implement and it wouldn't require any
changes at the library level.
Yes counting the nesting level like Twan proposed will definitely
solve the modularity problem.
I do think we need to optimize the block and unblock operations in
such a way that they don't need to use IORefs to save the counting
level. The version Twan posted requires 2 reads and 2 writes for a
block and unblock. While I haven't profiled it I think it's not very
efficient.
Oh, I thought that was pseudocode to illustrate the idea. Where would
you store the IORef, for one thing? No, I think the only sensible way
is to build the nesting semantics into the primitives.
Incedentally, I've been using the term "mask" rather than "block" in this
context, as "block" is far too overloaded. It would be nice to change the
terminology in the library too, leaving the old functions around for
backwards compatibility of course.
Indeed "block" is to overloaded. I've been using block and unblock a
lot in concurrent-extra[1] and because this package deals with threads
that can "block" it sometimes is confusing whether a block refers to
thread blocking or asynchronous exceptions blocking.
So I'm all for deprecating 'block' in favor of 'mask'. However what do
we call 'unblock'? 'unmask' maybe? However when we have:
mask $ mask $ unmask x
and these operations have the counting nesting levels semantics,
asynchronous exception will not be unmasked in 'x'. However I don't
currently know of a nicer alternative.
But that's the semantics you wanted, isn't it? Am I missing something?
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
