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