Interruptible GHC

[Simon Marlow]

On 11/09/2010 07:59, Edward Z. Yang wrote:
> So I did a writeup of what I thought might be the next direction to
> go with the interruptible patch:
>
>      http://blog.ezyang.com/2010/09/towards-platform-agnostic-interruptibility/
>
> The really interesting bit (which I didn't cover) is what information
> to give to the user functioSo I did a writeup of what I thought might be the next direction to
> go with the interruptible patch:
>
>      http://blog.ezyang.com/2010/09/towards-platform-agnostic-interruptibility/
>
> The really interesting bit (which I didn't cover) is what information
> to give to the user function.  It needs to be somewhat under the
> hood: if someone wants to pthread_cancel they need to know what the pthreads
> ID is; if they want to transmit a Windows event they need some way to get
> a hold of the event handle associated with the foreign call.

The idea of having user-definable cancellation mechanisms seems quite 
sensible, given that we have so many ways to do this.  However it seems 
quite hard in practice: for pthread_cancel, the RTS has to behave quite 
differently from pthread_kill.  The API for defining the cancellation 
mechanism could get quite complicated.

For now I would go with 'interruptible' (meaning either pthread_kill() 
or CancelSynchronousIO()).  It's not nearly as dangerous as 
pthread_cancel(), but it covers a lot of the cases we're interested in, 
and it doesn't have problems with bound threads.

Cheers,
	Simon