mstefani at redhat.com
Fri Nov 5 13:08:35 CST 2004
Dimitrie O. Paun wrote:
> 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?
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.
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
And btw. you could easily do signal multiplexing with the real time
signals: you can send additional data with the signal if you use
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.
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbH Email: mstefani at redhat.com
Hauptstaetterstr. 58 http://www.redhat.de/
More information about the wine-devel