Opened 7 years ago

Closed 7 years ago

#4857 closed proposal (invalid)

Add Control.Exception.allowInterrupt

Reported by: simonmar Owned by:
Priority: normal Milestone: Not GHC
Component: libraries/base Version: 7.0.1
Keywords: Cc: mmitar@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonmar)

This proposal is to add the following function to Control.Exception:

-- | When invoked inside 'mask', this function allows a blocked
-- asynchronous exception to be raised, if one exists.  It is
-- equivalent to performing an interruptible operation (see
-- #interruptible#), but does not involve any actual blocking.
--
-- When called outside 'mask', or inside 'uninterruptibleMask', this
-- function has no effect.
allowInterrupt :: IO ()
allowInterrupt = unsafeUnmask $ return ()

Some discussion leading up to this can be found in #4810.

Discussion period: 3 weeks (until 12 Jan 2011)

Change History (9)

comment:1 Changed 7 years ago by simonmar

Description: modified (diff)

comment:2 Changed 7 years ago by simonmar

Description: modified (diff)

comment:3 Changed 7 years ago by mitar

Cc: mmitar@… added

comment:4 Changed 7 years ago by mitar

Why it should not have any effect inside the uninterruptibleMask?

comment:5 in reply to:  4 Changed 7 years ago by simonmar

Replying to mitar:

Why it should not have any effect inside the uninterruptibleMask?

This is a free design choice, although I think it makes more sense and is more consistent for allowInterrupt to be a no-op inside uninterruptibleMask. Think of allowInterrupt as an interruptible operation, like takeMVar, but one that just returns immediately without actually blocking.

comment:6 Changed 7 years ago by mitar

Hm, my initial idea was to make uninterruptibleMask more useful if you can also (at precise location) accept exception inside it.

Maybe we should need two allowInterrupt functions? And leave to developers to choose the one they want?

comment:7 Changed 7 years ago by simonmar

Well, I just realised the current implementation has the behaviour you want anyway (i.e. it allows interrupts even inside uninterruptibleMask). I don't feel strongly about this.

comment:8 Changed 7 years ago by igloo

Milestone: Not GHC

comment:9 Changed 7 years ago by igloo

Resolution: invalid
Status: newclosed

Proposal tickets are no longer needed as part of the library submissions process. Instead, a normal ticket should be created once consensus has been achieved. Please see the process description for details.

Note: See TracTickets for help on using tickets.