Very Computer

by **Pirabhu Rama** » Sat, 10 May 2003 00:17:52

Hi,

Is it possible for just a single thread to fail in a Multi-threaded
application? ( including cases where threads are created as light-weight
processes)
If so, how do I detect the failure of that thread from any other thread.
Assume no join is performed on the threads.

Thanks in advance
Pirabhu

ps: Did a brief search in FAQ but couldn't find similar questions. Please
point out the relevant link if similar question was already posted.

----------------------------------------------------------------
Hope is a dangerous thing. Hope can drive a man insane.

by **Marc Rochkin** » Sat, 10 May 2003 02:14:06

Quote:> Hi,

> Is it possible for just a single thread to fail in a Multi-threaded
> application? ( including cases where threads are created as light-weight
> processes)
> If so, how do I detect the failure of that thread from any other thread.
> Assume no join is performed on the threads.

Maybe others know what you mean, but for me, could you define "fail?"

--Marc

by **Pirabhu Rama** » Sat, 10 May 2003 02:20:43

> > Hi,

> > Is it possible for just a single thread to fail in a Multi-threaded
> > application? ( including cases where threads are created as light-weight
> > processes)
> > If so, how do I detect the failure of that thread from any other thread.
> > Assume no join is performed on the threads.

> Maybe others know what you mean, but for me, could you define "fail?"

> --Marc

By fail I meant the death of the thread. eg in linux every thread is given a
separate PID. What if one of the thread alone dies? (Is it possible?) Will I
get any signal (like in fork we get a SIGCHLD)

by **Grant Taylo** » Sat, 10 May 2003 02:54:50

> By fail I meant the death of the thread. eg in linux every thread is
> given a separate PID. What if one of the thread alone dies? (Is it
> possible?) Will I get any signal (like in fork we get a SIGCHLD)

On Linux, yes; with LinuxThreads each thread is merely a process which
shares 100% of it's memory map with other processes. Signal behavior
follows exactly as the model implies.

I've never used sigchld in a threaded app on Linux, but I have written
a sampling profiler using SIGPROF which profiled just one specific
thread. Linux's model made this completely trivial. Other things
become more awkward...

--
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/

by **David Schwart** » Sat, 10 May 2003 06:31:33

Quote:> By fail I meant the death of the thread. eg in linux every thread is given
a
> separate PID. What if one of the thread alone dies? (Is it possible?) Will
I
> get any signal (like in fork we get a SIGCHLD)

Dies how? You're still not explaining what you mean. Give an example of
how or why a thread could die.

DS

by **Marc Rochkin** » Sat, 10 May 2003 06:46:08

There may be a basic misunderstanding on the part of the OP as to how a
POSIX thread can be terminated. It can be cancelled or it can exit.

A thread can't be terminated by a signal, even if the signal is directed to
the thread and not to the process. Any such signal would terminate the
entire process.

--Marc

by **Pirabhu Rama** » Sat, 10 May 2003 06:59:45

Quote:> There may be a basic misunderstanding on the part of the OP as to how a
> POSIX thread can be terminated. It can be cancelled or it can exit.

> A thread can't be terminated by a signal, even if the signal is directed
to
> the thread and not to the process. Any such signal would terminate the
> entire process.

Yes I know that signals are delivered to all the threads and the scheduler
will select the particular thread, if the thread has not blocked the signal.
There a few cases which I want to clarify
1) Are there any extreme cases like single event upsets or some Byzantine
cases where only one thread can fail?
2)If a maskable signal such as SIGINT is delivered to the process and all
but one thread blocks the signal what is the behavior? Does the whole
process get killed even though the other threads blocked the signal?

Thanks in advance

by **Marc Rochkin** » Sat, 10 May 2003 07:14:22

Quote:> > There may be a basic misunderstanding on the part of the OP as to how a
> > POSIX thread can be terminated. It can be cancelled or it can exit.

> > A thread can't be terminated by a signal, even if the signal is directed
> to
> > the thread and not to the process. Any such signal would terminate the
> > entire process.

> Yes I know that signals are delivered to all the threads and the scheduler
> will select the particular thread, if the thread has not blocked the
signal.
> There a few cases which I want to clarify
> 1) Are there any extreme cases like single event upsets or some Byzantine
> cases where only one thread can fail?

I would say that there are no such cases in the standard, but a defective
implementation is free to do anything it likes. I don't think this needs to
be programmed for.

Quote:> 2)If a maskable signal such as SIGINT is delivered to the process and all
> but one thread blocks the signal what is the behavior? Does the whole
> process get killed even though the other threads blocked the signal?

Yes. The specification doesn't allow terminate, stop, continue, or ignore to
affect only one thread. Actually, ALL actions are for the process as a
whole. There is no pthread_sigaction function, and sigaction takes no
thread-ID argument.

The only reason why a caught signal appears to affect only one thread is
just that it gets caught only once (per occurrence), and the handler has to
execute someplace.

--Marc

by **David Schwart** » Sat, 10 May 2003 07:15:44

Quote:> 1) Are there any extreme cases like single event upsets or some Byzantine
> cases where only one thread can fail?

You're asking *us* what *you* mean by "fail". We have no idea.

Quote:> 2)If a maskable signal such as SIGINT is delivered to the process and all
> but one thread blocks the signal what is the behavior? Does the whole
> process get killed even though the other threads blocked the signal?

If the default behavior of SIGINT is to kill the process and a thread
that has not blocked SIGINT gets a SIGINT, then the process is supposed to
be killed.

DS

by **Alexander Terekho** » Sat, 10 May 2003 18:11:43

[...]

Quote:> On Linux, yes; with LinuxThreads each thread is merely a process which
> shares 100% of it's memory map with other processes. Signal behavior
> follows exactly as the model implies.

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/release-notes/x86

"....
Red Hat Linux 9 includes the Native POSIX Thread Library (NPTL), a
new implementation of POSIX threads for Linux. This library provides
performance improvements and increased scalability for i686 or better
processors.

This thread library is designed to be binary compatible with the old
LinuxThreads implementation; however, applications that rely on the
places where the LinuxThreads implementation deviates from the
POSIX standard will need to be fixed. Notable differences include:

- Signal handling has changed from per-thread signal handling to
POSIX process signal handling.

- getpid() returns the same value in all threads.

...."

regards,
alexander.

by **Marc Rochkin** » Sat, 10 May 2003 22:37:06

[snip]

Quote:> new implementation of POSIX threads for Linux.

[snip]

Quote:> - Signal handling has changed from per-thread signal handling to
> POSIX process signal handling.

> - getpid() returns the same value in all threads.

Which means it is NOT an implementation of POSIX Threads! ("Almost" and
"not" are usually interchangeable words.)

--Marc

by **g..** » Sat, 10 May 2003 22:50:27

Quote:> [snip]

>> new implementation of POSIX threads for Linux.

> [snip]

>> - Signal handling has changed from per-thread signal handling to
>> POSIX process signal handling.

>> - getpid() returns the same value in all threads.

> Which means it is NOT an implementation of POSIX Threads! ("Almost" and
> "not" are usually interchangeable words.)

well, as I can see neither "almost" or "not" in the above text, you
appear to talking rubbish.

-tony

by **Alexander Terekho** » Sat, 10 May 2003 23:14:26

> [snip]

> > new implementation of POSIX threads for Linux.

> [snip]

> > - Signal handling has changed from per-thread signal handling to
> > POSIX process signal handling.

> > - getpid() returns the same value in all threads.

> Which means it is NOT an implementation of POSIX Threads! ("Almost" and
> "not" are usually interchangeable words.)

C'mon, "NPTL's" getpid() returns the process ID of the calling POSIX
process -- the same value in all its threads.

regards,
alexander.

by **Marc Rochkin** » Sat, 10 May 2003 23:26:42

> > [snip]

> > > new implementation of POSIX threads for Linux.

> > [snip]

> > > - Signal handling has changed from per-thread signal handling to
> > > POSIX process signal handling.

> > > - getpid() returns the same value in all threads.

> > Which means it is NOT an implementation of POSIX Threads! ("Almost" and
> > "not" are usually interchangeable words.)

> C'mon, "NPTL's" getpid() returns the process ID of the calling POSIX
> process -- the same value in all its threads.

> regards,
> alexander.

Right... misread the "changed from per-thread" part of the post. If it now
conforms, this is terrific!

--Marc

by **Valentin Nechaye** » Sat, 10 May 2003 23:49:42

>> new implementation of POSIX threads for Linux.
MR> [snip]
>> - Signal handling has changed from per-thread signal handling to
>> POSIX process signal handling.

>> - getpid() returns the same value in all threads.

MR> Which means it is NOT an implementation of POSIX Threads!

Why?

-netch-