Exception handler missimg in GHC.Handle.hs

[Simon Marlow]

> If someone has aknowledged this problem, please reply, I'm=20
> getting the feeling nobody want's to do anything about it...

I've been away for a few days, and I'm now catching up.  Sorry for the
delay.

> Brief description: if the remote side of a socket closes the=20
> connection,=20
> any write will cause a sigPIPE signal, if a
> signal handler ignoring the signal is in place this results in an IO=20
> exception in the write call (or flush). At this point
> the local end of the socket still exists and needs to be closed by a=20
> call to c_close, howerver, hClose and the finalizer
> both try to flush the write side causeing a second exception,=20
> resulting=20
> in the handle never getting closed, and leaking...
>=20
> Here is a potential solution: (maybe better to use catchJust ioErrors)
>=20
> handleFinalizer :: MVar Handle__ -> IO ()
> handleFinalizer m =3D do
>     h_ <- takeMVar m
>     catch (flushWriteBufferOnly h_) (\e -> return()) -- catch=20
> exception=20
> if remote side closed
>     let fd =3D fromIntegral (haFD h_)
>         unlockFile fd
>         when (fd /=3D -1)
> #ifdef mingw32_TARGET_OS
>          (closeFd (haIsStream h_) fd >> return ())
> #else
>         (c_close fd >> return ())
> #endif
>         return ()

Yes, that's a good bug.  The buffer flushing operations are
interruptible, so we should guard against asynchronous exceptions being
delivered at those points.

Cheers,
	Simon