Here's what the Windows version would look like (if I could get HEAD
to build, that is :-)
void
interruptOSThread (OSThreadId id)
{
HANDLE hdl;
PCSIO pCSIO;
if (!(hdl = OpenThread(THREAD_TERMINATE,FALSE,id))) {
sysErrorBelch("interruptOSThread: OpenThread");
stg_exit(EX
It looks like the problem was that the default handler for SIGINT
was scheduling code to run, when we really just wanted to get EINTR.
I'm sketchily using SIGPIPE right now; maybe we should use SIGUSR1
or something.
Edward
___
Glasgow-haskell-users maili
There are some invariants that are being violated by pthread_kill(id, SIGINT)
and I'm having difficulty understanding them. I get the following errors:
cd ./concurrent/should_run && '/home/ezyang/Dev/ghc/inplace/bin/ghc-stage2'
-fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -rtsopts
Excerpts from Simon Marlow's message of Wed Sep 15 04:34:06 -0400 2010:
> It's not clear to me when to emit the warning: the system we're
> compiling on is not necessarily the one we're going to run on. This is
> more often the case for us where we're building distributions, than for
> other pe
On 15/09/2010 03:33, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Mon Sep 13 05:10:13 -0400 2010:
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_can
Excerpts from Simon Marlow's message of Mon Sep 13 05:10:13 -0400 2010:
> 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
> di
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
t
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 o
