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.
http://blog.ezyang.com/2010/09/pthread-cancel-on-window/
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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
