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