strange pthreads behaviour

From: Raśl (
Date: Sat Dec 14 2002 - 11:51:36 EST


I've encountered an extrange behaviour with pthreads in a piece of code
I'm developing for linux 2.4.18-18.8.0 (RH-8.0) glibc-2.2.93

Basically the app is an CORBA servant object (omniORB-4.0 based) that
maps some of the methods of the idl for the object on scripts or

I've considered POSIX semantics por signal delivery in MT

The app works this way:

1) SIGCHLD is blocked in main() thread first of all.
2) ORB threads are started (they should inherit SIGCHLD blocked)
3) on a request, one working-thread from the request broker will
eventually call spawn_script()
4) a sigmask with SIGCHLD unblocked is prepared for posterior usage on
5) spawn_script() forks. If I am right the fork() from the thread will
create a brand new process with the only execution context of the
calling thread.
6) forked process execve()'s the script (after duping fd0 & 1 on a
7) parent thread enters in a pselect() loop to read child's stdout from
the pipe.
8) the exit condition for the loop is raised when pselect() catches

The only point where SIGCHLD is unblocked is inside pselect() & calls to
spawn_script() are serialized using a global mutex. So I can ensure that
only the thread inside pselect() has SIGCHLD unblocked, so when the
child exits the notification will arrive to the correct thread on the
parent process. And, in fact, it seemed to work.

The problem is that execve() works only if called from the main()
thread. If called from another thread it blocks forever inside

The stack-trace for the process blocked on execve looks like:

spawn_script(const char*, char**, char***)

execve() is called from the fork()ed process so it should not have any
related thread.
There are no blocked signals when calling execve().

I've also tried the non-portable function
pthread_kill_other_threads_np() before execve() but
pthread_kill_other_threads_np() will also block on sigsuspend() with an
obviously similar stack-trace:

spawn_script(const char*, char**, char***)

Is this behaviour normal?
Why does the forked process block on

Thanks in advance.

        Raul Saura

PD: please CC the eventual asnwers to

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:31 EST