From: Raúl <raul.saura@telefonica.net>
To: linux-kernel@vger.kernel.org
Cc: rsaura@retevision.es
Subject: strange pthreads behaviour
Date: 14 Dec 2002 17:51:36 +0100 [thread overview]
Message-ID: <1039884697.1094.26.camel@localhost.localdomain> (raw)
[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]
Hello,
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
executables.
I've considered POSIX semantics por signal delivery in MT
applications.
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
pselect()
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
pipe)
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
SIGCHLD
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
sigsuspend().
The stack-trace for the process blocked on execve looks like:
__libc_start_main
main
Conector_i::leerFicheroPropiedades(char*)
spawn_script(const char*, char**, char***)
exevce
pthread_kill_other_threads_np
pthread_oneexit_process
_pthread_wait_for_restart_signal
sigsuspend
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:
__libc_start_main
main
Conector_i::leerFicheroPropiedades(char*)
spawn_script(const char*, char**, char***)
pthread_kill_other_threads_np
pthread_oneexit_process
_pthread_wait_for_restart_signal
sigsuspend
Is this behaviour normal?
Why does the forked process block on
execve()/_pthread_wait_for_restart_signal()?
Thanks in advance.
Raul Saura
PD: please CC the eventual asnwers to raul.saura@telefonica.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
reply other threads:[~2002-12-14 16:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1039884697.1094.26.camel@localhost.localdomain \
--to=raul.saura@telefonica.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rsaura@retevision.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.