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 didn't say that it didn't work anywhere else; I only tried it on Mac OS X, and it works there; it might work elsewhere, too, but documentation I found online tells me that the pthread_mutex_* functions may *never* be called from signal handlers. I'm sure there are systems where it'll fail.
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?
Perhaps; we might get away with using the same atomic increment operations to read from the buffer.
Ad 3)
I'm really not sure what happens when two signal handlers try to write to the same pipe at the same time. Are multi-byte writes from separate threads atomic with respect to each other? They seem to be on Mac OS, but I'd prefer a written guarantee... But see 6) below.
I've got two more ideas:
5) Block signals everywhere but in the thread that currently runs Haskell code. Does not work on systems that don't support proper POSIX semantics, most notably all but very recent versions of Linux (the new Native Posix Thread Library for Linux is said to fix this).
6) Block signals everywhere but in the main thread. No problem even for older Linuxes; the problem of sending the data from the signal handler to the scheduler loop remains (they may be in different threads), but the pipe solution will definitely work because there won't be two signal handlers writing to the pipe at the same time.
Cheers,
Wolfgang
_______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
