Concurrent Haskell, asynchronous exceptions and interruptibility (again)

Andrew Moran moran@galois.com
Wed, 30 Oct 2002 07:40:10 -0800


On Wednesday 30 October 2002 01:20 am, Simon Marlow wrote:

> Not unless the putMVar blocks. The proof that it never blocks depends
> on the behaviour of other threads though: if you have another thread
> doing putMVar on the same MVar, then it may block.  Other threads must
> be "well-behaved" for it to work.

At first glance, this seems like an untenable situation, but it's not rea=
lly. =20
The mechanisms provided in GHC are quite low-level.  Careful design of=20
higher-level combinators (implemented in terms of block/unblock, etc.)=20
appropriate to the problem at hand is essential.  If all of threads use t=
he=20
high-level combinators, you can guarantee that they're all well-behaved.

A common idiom is the "with<Resource>" style of combinator.  Here's=20
withSocket, which guarantees that the socket will be closed at the end of=
 the=20
withSocket, even if the thread using it is killed:

withSocket :: Socket -> (Socket -> IO a) -> IO a
withSocket sock ioa =3D finally (ioa sock) (sClose sock)

A similar idea works for shared resources; see=20
Control.Concurrent.MVar.withMVar for the classic example.  It changes the=
 way=20
your code looks pretty dramatically, but it makes the job of debugging=20
multi-threaded, multi-process programs much easier.

Cheers,

Andy

--
Andy Moran
Galois Connections Inc.                                 Fax. (503) 350 08=
33
3875 SW Hall Blvd.                                    http://www.galois.c=
om
Beaverton, OR 97005                                        moran@galois.c=
om