Home > Archive > Unix Programming > June 2007 > pthreads and signals
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
pthreads and signals
|
|
| Boltar 2007-06-13, 10:05 pm |
| Hi
This is probably an old old question, but if you have a multithreaded
app and you haven't set up a specific signal handling thread (all
threads bar one block all possibly signals) , is there a rough guide
to know which thread will get the signal? Is it the parent thread, the
thread currently in context or one chosen by some other logic? Does it
vary between unixes (I know about old linux "threads" actually being
processes so I'm not refering to that)?
Thanks for any info
B2003
| |
| Rainer Weikusat 2007-06-13, 10:05 pm |
| Boltar <boltar2003@yahoo.co.uk> writes:
> This is probably an old old question, but if you have a multithreaded
> app and you haven't set up a specific signal handling thread (all
> threads bar one block all possibly signals) , is there a rough guide
> to know which thread will get the signal?
It should be possible to determine this by looking at the respective
library and kernel sources, insofar available. But why do you want to
know this? Which of the threads of some process would be a good choice
for running a signal handler NOW is a descision the 'thread
scheduler' (be it the general scheduler in the kernel or 'someone
else') can 'intelligently' make because it has (or should have)
information on what all those threads are currently doing (eg being
blocked waiting for something or running on CPU) and were doing in the
past available.
[...]
> (I know about old linux "threads" actually being processes so I'm
> not refering to that)?
Please repeat after me (three times):
Robert Love is a moron.
Ok, after having cleared the air in this respect: 'Linux threads' are
not 'actually processes', that's a statement that doesn't make any
sense, because 'a process' is defined to be a set of ressources (like
an address spaces), shared by one or more threads of execution. The
Linux kernel implements 'kernel scheduled entities' as 'tasks',
described by a struct task_struct holding pointer to various ressource
belonging to that task (eg address space or file descriptor table). A
syscall named 'clone' exists which creates a copy of an existing
struct task_struct, and, depending on a flag argument passed to it,
either allocates new 'ressource structures' for the cloned task or
makes it reference the same the original task referenced. Depending on
what is shared and what not, this mechanism can be used to implement
both 'traditional' single-threaded UNIX(*) processes and 'UNIX(*)
pthreads'.
| |
| Boltar 2007-06-13, 10:05 pm |
| On 13 Jun, 16:42, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Ok, after having cleared the air in this respect: 'Linux threads' are
> not 'actually processes', that's a statement that doesn't make any
On my linux 2.4 setup each thread has a seperate process id and can be
sent signals based on process id. To me that means they're seperate
processes that happen to have a special mechanism using some other
special process to emulate threading. 2.6 supports real threading.
B2003
| |
| Rainer Weikusat 2007-06-13, 10:05 pm |
| Boltar <boltar2003@yahoo.co.uk> writes:
> On 13 Jun, 16:42, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
> On my linux 2.4 setup each thread has a seperate process id and can be
> sent signals based on process id. To me that means
It doesn't matter the least bit what you 'believe' this to be, because
it is the way I described it. For 2.6, a 'thread group id' was added
to the task_struct which serves as (shared) process id for
multi-threaded processes and what used to be 'the process id' has
become 'the thread id'. The particulars of the thread implementation
itself are the same (there are a few non-relevant differences).
For the Linux kernel, the terms 'process' and 'thread' are
meaningless, because all the kernel knows about are tasks, which share
or don't share sets of ressources.
| |
| Frank Cusack 2007-06-13, 10:05 pm |
| On Wed, 13 Jun 2007 07:24:37 -0700 Boltar <boltar2003@yahoo.co.uk> wrote:
> This is probably an old old question, but if you have a multithreaded
> app and you haven't set up a specific signal handling thread (all
> threads bar one block all possibly signals) , is there a rough guide
> to know which thread will get the signal?
For so-called synchronous signals (e.g. PIPE,SEGV), they are supposed
to be held pending against the thread that generated it. But
implementations differ.
Otherwise (e.g. HUP), any thread might get it.
> Is it the parent thread,
What is a parent thread?
-frank
| |
|
| Hi,
> This is probably an old old question, but if you have a multithreaded
> app and you haven't set up a specific signal handling thread (all
> threads bar one block all possibly signals) , is there a rough guide
> to know which thread will get the signal? Is it the parent thread, the
> thread currently in context or one chosen by some other logic? Does it
> vary between unixes (I know about old linux "threads" actually being
> processes so I'm not refering to that)?
Firstly, signal handler is per process resource:) and it is one for
every threads in the process, but each thread has signal mask. Also,
as I remember, there is no standard way to determinate the context of
signal handler (I mean in which thread it is executing). So you could
block your signal in each thread except one, and you'll be sure that
signal handler is executed in context of this thread. In all other
cases, signal handler could be executed in context of any thread where
such signal was not blocked or ignored.
Regards,
Volodymyr!
| |
| Frank Cusack 2007-06-14, 7:06 pm |
| On Thu, 14 Jun 2007 01:49:06 -0700 TvN <tvntsr@yahoo.com> wrote:
> In all other cases, signal handler could be executed in context of
> any thread where such signal was not blocked or ignored.
Not correct. Synchronous signals are required to be delivered to
the thread that generated them.
-frank
| |
| Boltar 2007-06-14, 7:06 pm |
| On Jun 13, 5:05 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> For the Linux kernel, the terms 'process' and 'thread' are
> meaningless, because all the kernel knows about are tasks, which share
> or don't share sets of ressources.
I'm not interested in what really happens in the kernel, what concerns
me is how the processes/threads interact with parts of libc. If they
don't behave like threads in all situations (eg when calling
getpid() , kill() etc) then they're not real threads. Period.
B2003
| |
| Boltar 2007-06-14, 7:06 pm |
| On Jun 13, 7:17 pm, Frank Cusack <fcus...@fcusack.com> wrote:
> What is a parent thread?
I just meant the initial thread of the process that spawned all the
others.
B2003
| |
| Casper H.S. Dik 2007-06-14, 7:06 pm |
| Boltar <boltar2003@yahoo.co.uk> writes:
>On Jun 13, 7:17 pm, Frank Cusack <fcus...@fcusack.com> wrote:
[color=darkred]
>I just meant the initial thread of the process that spawned all the
>others.
It has no particular standing in the threading model.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Frank Cusack 2007-06-14, 7:06 pm |
| On Thu, 14 Jun 2007 02:32:46 -0700 Boltar <boltar2003@yahoo.co.uk> wrote:
> On Jun 13, 7:17 pm, Frank Cusack <fcus...@fcusack.com> wrote:
Wow, the google groups interface actually wastes its effort to
munge the attribution that way? laughable.
| |
| Rainer Weikusat 2007-06-14, 7:06 pm |
| Boltar <boltar2003@yahoo.co.uk> writes:
> On Jun 13, 5:05 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
> I'm not interested in what really happens in the kernel,
> what concerns me is how the processes/threads interact with parts of
> libc.
This statement parses as 'I am not interested in the process/ thread
implementation but only in the process/ thread implementation'. Which
kind-of contradicts itself. To repeat this again:
A process is (for UNIX(*)) defined as:
3.289 Process
An address space with one or more threads executing within
that address space, and the required system resources for
those threads.
and a thread is defined as:
3.393 Thread
A single flow of control within a process. Each thread has its
own thread ID, scheduling priority and policy, errno value,
thread-specific key/value bindings, and the required system
resources to support a flow of control. Anything whose address
may be determined by a thread, including but not limited to
static variables, storage obtained via malloc(), directly
addressable storage obtained through implementation-defined
functions, and automatic variables, are accessible to all
threads in the same process.
> If they don't behave like threads in all situations (eg when calling
> getpid() , kill() etc) then they're not real threads.
If 'they' don't have an address space of their own, 'they' are not
processes, see definition above. And the (correct) statement that 'the
LinuxThreads implementation isn't compliant with the POSIX thread
specification' is rather different from 'old Linux threads are
processes'.
| |
|
| On Jun 14, 9:18 am, Frank Cusack <fcus...@fcusack.com> wrote:
> On Thu, 14 Jun 2007 01:49:06 -0700 TvN <tvn...@yahoo.com> wrote:
>
>
> Not correct. Synchronous signals are required to be delivered to
> the thread that generated them.
>
I was talking about signal handler, not signal delivery ;) Would
signal handler be executed if signal was blocked in the thread? I
think no ;)
Regards,
Volodymyr!
| |
|
|
|
|
|
|
|