SIGALRM, SIGVTALRM, and third party libraries

[Simon Marlow]

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