|Title||Thread suspension interface is hacky, error-prone|
|Assigned user||Gareth Rees|
|Description||On Unix, the MPS uses the signals SIGXCPU and SIGXFSZ in order to suspend threads. This has the following bad consequences:|
1. The client program must not mask these signals. 
2. If a client program needs to handle these signals, there's no documented interface for doing this: at the moment you have to hack the MPS.
3. It looks bad in the documentation.
|Analysis||The justification for using this mechanism is as follows:|
1. POSIX threads provide no portable way to suspend a thread (there's pthread_suspend, but this is not implemented on Linux or FreeBSD).
2. We can't reliably use any particular signal (for example, SIGUSR1 and SIGUSR2 are already in use by several systems, including ValGrind and Boehm ) and SIGXCPU and SIGXFSZ were picked as being least likely to be used by anyone.
It would be nice to use some better mechanism on Linux for this, one that didn't lead to the problem that "you cannot actually use something like ValGrind and for example, the Boehm GC in one program" , but there doesn't seem to be one. A simple thing that might solve much of the problem would be to provide a documented interface by which the client program can swap out these signals, for example -DCONFIG_PTHREADEXT_SIGSUSPEND=SIGXCPU -DCONFIG_PTHREADEXT_SIGRESUME=SIGXFSZ.
(We can't specify these signals using keyword arguments to mps_arena_create_k, because this isn't per-arena information: all arenas must share the same set of signals).
|Created by||Gareth Rees|
|Created on||2013-07-04 14:35:51|
|Last modified by||Gareth Rees|
|Last modified on||2016-09-04 13:55:39|
|History||2013-07-04 GDR Created.|
|192122||closed||2016-09-04 13:55:39||Gareth Rees||New preprocessor constants CONFIG_PTHREADEXT_SIGSUSPEND and CONFIG_PTHREADEXT_SIGRESUME for configuring the signals used to suspend and resume threads.|