[ duh, hit send by mistake, message continues... ] Chris Kuklewicz wrote:
forkInheritIO :: IO () -> IO ThreadId -- inherits parent's block or unblock status
forkBlockedIO :: IO () -> IO ThreadId -- starts the action in "block" mode. Must manually "unblock"
Either of these is certainly possible, and I agree that forkBlockedIO is more generally useful than my forkCatchIO. One tantalising possibility is that we could make forkIO have the forkInheritIO behaviour without breaking much code, since I bet forkIO is almost never called inside block. Cheers, Simon
On Mon, Dec 04, 2006 at 12:43:00PM +0000, Simon Marlow wrote:
Chris Kuklewicz wrote:
forkInheritIO :: IO () -> IO ThreadId -- inherits parent's block or unblock status
forkBlockedIO :: IO () -> IO ThreadId -- starts the action in "block" mode. Must manually "unblock"
Either of these is certainly possible, and I agree that forkBlockedIO is more generally useful than my forkCatchIO.
One tantalising possibility is that we could make forkIO have the forkInheritIO behaviour without breaking much code, since I bet forkIO is almost never called inside block.
This would indeed be tantalizing (speaking as someone who hasn't used concurrent Haskell in five or so years, and spelling as an american), but mightn't it lead to hard-to-find bugs where people happen to be calling forkIO when they're in blocked mode? Both block and asynchronous exceptions are relatively rare, but they do occur together, and where they occur, programmers must have carefully thought out how they interact. -- David Roundy Department of Physics Oregon State University
participants (2)
-
David Roundy -
Simon Marlow