There are plenty of signals available to applications besides SIGUSR1 and SIGUSR2. This are the real time signals in the range SIGRTMIN ... SIGRTMAX specified by POSIX 1003.1-2001. The only main difference to the "normal" signals is that this signals can be queued.On Thu, Nov 04, 2004 at 08:02:24PM +0000, Mike Hearn wrote:
Long term the plan is to use SIGUSR2 to implement SetThreadContext, with SIGUSR1 uploading the sigcontext to the server for GetThreadContext like in the patch.
That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring out how to overload SIGUSR2).
Sorry if I'm way off (haven't looked at the problem myself), but can't we include a command-byte or so with the payload (in the case the context), so we can multiplex multiple requests on the same signal?
From man signal(7):
Unlike standard signals, real-time signals have no predefined meanings:
the entire set of real-time signals can be used for application-defined
purposes.
And btw. you could easily do signal multiplexing with the real time signals: you can send additional data with the signal if you use sigqueue(2).
The question now is how portable this is. Linux has SIGRTMIN ... SIGRTMAX at least in the 2.4 and 2.6 kernels, Solaris and Irix (from Google hits) seem to have it too, but i don't know about the *BSD variants including Darwin.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbH Email: [EMAIL PROTECTED]
Hauptstaetterstr. 58 http://www.redhat.de/
D-70178 Stuttgart