It seems I found a pretty serious bug in Pth related to signal handling
in the scheduler thread. In particular the following piece of code in
pth_sched.c:
/* determine signals we block */
for (sig = 1; sig < PTH_NSIG; sig++)
if (!sigismember(&(t->mctx.sigs), sig))
sigdelset(&pth_sigblock, sig);
It seems that t->mctx.sigs isn't really used, at least it is always
initialized as the empty set. So we always *unblock all signals* in the
scheduler, which is probably not what we want. I'd say that the
scheduler should always block all signals and rely on the other threads
to handle signals.
My particular application needs to deal with signals arriving at random
times, that's why I carefully block signals in the threads I'm running.
But if the scheduler runs with all signals unblocked, this doesn't work.
Simply *removing the quoted block* of code solves the problem for me,
but it might be a too simple solution. I don't understand the use of
t->mctx.sigs well enough to determine whether this is truly the "right"
solution.
Best regards,
Jeroen.
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
Development Site http://www.ossp.org/pkg/lib/pth/
Distribution Files ftp://ftp.gnu.org/gnu/pth/
Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/
User Support Mailing List pth-users@gnu.org
Automated List Manager (Majordomo) pth-users-requ...@gnu.org
