> > Could you just use the pipe as a wakeup mechanism, and
> store the signal
> > information in another buffer? I imagine we'll probably
> want to store
> > more than just the signal number anyway (eg. for SIGCHLD we want to
> > store the pid of the process that completed).
>
> Wakeup is not the only problem here; the problem is synchronisation.
> How can we serialize access to that "other buffer" if we have
> multiple
> signals arriving in multiple threads?
Can't you protect the buffer with a mutex? You would presumably have to
prevent deadlock by a signal arriving while the mutex is held, but you
can do that by blocking signals around the critical sections. Or is
this what you meant by the pthread_mutex implementation that only works
on MacOS X?
> I'll see if I can send all the data over the pipe - if I make
> sure the
> write is not interrupted, it should be atomic... or isn't it?
> If pipes don't work, we're running out of portable options:
>
> 1) the currently implemented method - resending every signal to the
> thread that does select() - works, but readline interferes with this.
>
> 2) using pthread_mutexes works on Mac OS X, but is not guaranteed to
> work anywhere else.
>
> 3) sending everything over a pipe - might work
>
> 4) using atomic increment operations to access a buffer - definitely
> works, but is there a platform-independent API for this?
With (4), you'd still have to block signals around critical sections in
the scheduler which read the buffer, right?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
