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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
