MPS issue job003535

TitleThread suspension interface is hacky, error-prone
Assigned userGareth Rees
DescriptionOn 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]
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.
AnalysisThe 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 [3]) 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" [1], 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).
How foundinspection
Evidence[1] <>
[2] <>
[3] <>
Observed in1.111.0
Created byGareth Rees
Created on2013-07-04 14:35:51
Last modified byGareth Rees
Last modified on2016-09-04 13:55:39
History2013-07-04 GDR Created.


Change Effect Date User Description
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.