[qmtest] [PATCH] Use processes instead of threads

[Zack Weinberg]

Nathaniel Smith <njs at pobox.com> writes:
> On Wed, Apr 28, 2004 at 09:04:10PM -0700, Mark Mitchell wrote:
>> I think the best solution would just be to call sigprocmask after fork 
>> in executable.py, if the caller supplies a mask.  The built-in test 
>> classes should provide a mask with no signals blocked.  (We actually 
>> want this for ProcessTarget as well -- if QMTest were ever to block 
>> signals itself, or be exec'd from a process that blocked signals, we'd 
>> get weird behavior in the children even with ProcessTarget.)
>
> Arguably that would be okay, on the theory that if our caller blocked
> our signals, its because they wanted our signals to be blocked.  That
> is not a use case I'm particularly worried about, though...

It comes up in old (pre-job control) shells which would do
backgrounding partially by blocking SIGINT in the child process.  I am
not particularly concerned about this either, but it does seem more
abstractly correct to me to record the signal mask at startup (before
creating any threads) and restore that after fork.

I might be inclined to patch the Python core to do this, using
pthread_atfork, except that wouldn't help us.

> I guess it wouldn't be hard to whip up such a module anyway, though.
> Is NSIG available cross-platformly?  If so then it's easy to write
> set_sigmask()/get_sigmask(); if not then clear_sigmask() is still easy
> to write.

I don't see why you need NSIG ... make your module wrap sigset_t
objects, provide the sigaddset/sigdelset/... interface (with less
gruesome names), and the C library will do the checking for you.  Any
platform that has sigprocmask can be assumed to have these (they're
both POSIX.1).

zw