On 08/09/2010 15:57, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Wed Sep 08 03:40:42 -0400 2010:
Maybe. As a first step I think we could just document what happens when a call is interrupted (pthread_cancel() on POSIX, ??? on Windows) and let the user handle it. Is there even a good lowest-common-denominator that we can build an API on top of?
I've been thinking carefully about this, and I kind of suspect one-size fits all won't work here. I've done a writeup here; one of the problems with moving pthread_cancel to Windows is that its semantics are so complicated.
I don't think porting pthreads to Windows is the right way to handle this anyway, Windows programmers want to use Windows APIs. I suggest that we use CancelSynchronousIO if it is available, and otherwise do nothing (this means a dynamic binding which is a bit fiddly, but I think we already do this elsewhere). TerminateThread is out of the question, because it provides no way to block it or clean up. CancelSynchronousIO will let us interrupt threads blocked on I/O on Windows, which we can't currently do, and it works for both bound and unbound threads. On POSIX we can pthread_kill() bound threads. This will let us handle at least one important case I can think of: waitForProcess. We just have to find an appropriate signal to use - we can't use SIGVTALRM, because it is already set to SA_RESTART. Cheers, Simon