Layout for main()->pthread_create()->fork()->exec()->waitpid() etc.

[James Vanns]

All,

I shall try and briefly detail my ramblings in the subject...

I'm designing an application that will use threads, processes, signals
and execves - hopefully not in a mess either!? What I would like you to
do is comment on whether you see any problems with this theory:

Upon execution of the main process (e.g. via main()), before any new
processes or threads are executed I block all (possible) signals. After
this I create a new thread that will handle SIGHUP, SIGTERM and SIGINT
for the rest of the application (I don't want the other threads to
receive these signals).

After this an arbitrary number of threads will be executed... each one
of these threads will fork(). The child of thread n will restore the
old sigset_t (using pthread_sigmask ()) saved from main() and then
immediately execve() an external program. The reason for the restore of
the old (e,g, unblocked, default) sigset is so that the exec'd program
can be terminated, hup'd etc. as normal. Is this necessary? Or will the
exec set a new, default signal mask when the process image is
overwritten?

The parent of thread n will unblock SIGCHLD (again, using
pthread_sigmask ()) so it can receive the signal sent by the child
(upon exit) - I want to use waitpid to wait for this event (only in
this thread). When the parent recieves the return code of the child the
thread itself exits.

I've knocked up some relatively crude yet (I hope) accurate code and it
seems to work OK but are there any traps I should be aware of when
going about designing an app in this specific way?

Comments appreciated.

Regards,

Jim

[Marcin 'Qrczak' Kowalczyk]

Post by James Vanns
I've knocked up some relatively crude yet (I hope) accurate code and
it seems to work OK but are there any traps I should be aware of
when going about designing an app in this specific way?

Some implementations of threads have bugs in the area of signals
and don't work as POSIX specifies.

E.g. in old LinuxThreads a signal is always directed at a particular
thread, and other threads of the same process won't handle it. In NPTL
this is fine. I'm not sure whether this was exactly the old behavior
or whether it's working on all 2.6 kernels or only recently.

[James Vanns]

OK. This will *probably* not run on a version of Linux < 2.4.20 and run
on the majority of (hosts) 2.6. Was LinuxThreads fully replaced by NPTL
in 2.4.20?

Thanks.

Jim

[Marcin 'Qrczak' Kowalczyk]

Post by James Vanns
OK. This will *probably* not run on a version of Linux < 2.4.20 and run
on the majority of (hosts) 2.6. Was LinuxThreads fully replaced by NPTL
in 2.4.20?

Ordinarily NPTL requires features from 2.6 kernels. RedHat backported
them to its 2.4 kernels.

http://man-wiki.net/index.php/7:pthreads lists some issues with
LinuxThreads and NPTL wrt. which featuresare process-level and
thread-level.

[James Vanns]

Handy link - cheers.

Jim

[l***@gmx.net]

Hi James,

Post by James Vanns
OK. This will *probably* not run on a version of Linux < 2.4.20 and run
on the majority of (hosts) 2.6. Was LinuxThreads fully replaced by NPTL
in 2.4.20?

The first distributor that shipped NPTL with a 2.4.x kernel was Red-Hat
with Red Hat v9.0. There may be other distros that support NPTL for
2.4.x kernel. Namely the one that uses the corresponding Red-Hat kernel
(I remember of Gentoo for instance).

However the majority of such distros should have LinuxThreads.

HTH,
Loic.

[Steve Watt]

Post by James Vanns
I'm designing an application that will use threads, processes, signals
and execves - hopefully not in a mess either!? What I would like you to

That's an evil combination, there are a fair number of dark corners
in there.

[ snip creation of signal thread ]

Post by James Vanns
After this an arbitrary number of threads will be executed... each one
of these threads will fork(). The child of thread n will restore the
old sigset_t (using pthread_sigmask ()) saved from main() and then
immediately execve() an external program. The reason for the restore of
the old (e,g, unblocked, default) sigset is so that the exec'd program
can be terminated, hup'd etc. as normal. Is this necessary? Or will the
exec set a new, default signal mask when the process image is
overwritten?

What do you hope to gain by creating a thread to fork()?

Post by James Vanns
The parent of thread n will unblock SIGCHLD (again, using
pthread_sigmask ()) so it can receive the signal sent by the child
(upon exit) - I want to use waitpid to wait for this event (only in
this thread). When the parent recieves the return code of the child the
thread itself exits.

Threads don't have parents, processes have parents. All threads in
a process are peers.

Post by James Vanns
I've knocked up some relatively crude yet (I hope) accurate code and it
seems to work OK but are there any traps I should be aware of when
going about designing an app in this specific way?

Some specific traps are to watch out for mutex state after you've called
fork() -- mutexes locked in threads other than the one that called fork()
will not be unlocked unless you have arranged fork handlers (see
pthread_atfork) for them.

Also watch out that in the child process, after a fork(), the only
thread that exists is the one that called fork(). Any other threads
that were around are not copied.

Last, in a threaded process, you need to avoid calling any system
services except for a very small subset that are async signal safe
between the fork() and the exec().

Again, why do you think you need to create a thread for the fork()?