linux에서 thread사용에 대해

리눅스 쓰레드 구현은 clone으로 구현이 됩니다.

LinuxThreads provides kernel-level threads each thread is a separate
Unix process, sharing its address space with the other threads through
the new system call clone(). Scheduling between threads is handled by
the kernel scheduler, just like scheduling between Unix processes.

arch/i386/kernel/process.c
asmlinkage int sys_clone(struct pt_regs regs)
{
unsigned long clone_flags;
unsigned long newsp;

clone_flags = regs.ebx;
newsp = regs.ecx;
if (!newsp)
newsp = regs.esp;
return do_fork(clone_flags, newsp, &regs, 0);
}

kernel/fork.c에서 do_fork부분의 소스를 보면

각 상황별로 clone_flags를 가지고 다니면서, 처리가 이루어집니다.
리눅스가 이런 구조를 지니는 것은 기존의 구조를 변경을 최소화 하면서
쓰레드 기능을 구현을 하다보니.. 이렇게 된것이죠..

그리고 쓰레드를 사용하면
메인프로세스+쓰레드메니져 +쓰레드(1)...쓰레드(n) = N +2 란 공식이 나오게 되는데
이것은 제가 예전에 답글을 단적이 있으니 아래의 링크를 참조하세요
http//kldp.org/script/bbs/read.php?table=qa2&no=3628

쓰레드에서 시그널 문제는...
linuxthreads library의 README에 언급이 잘되어 있습니다.

http//pauillac.inria.fr/~xleroy/linuxthreads/README

- The current implementation uses the two signals SIGUSR1 and SIGUSR2,
so user-level code cannot employ them. Ideally, there should be two
signals reserved for this library. One signal is used for restarting
threads blocked on mutexes or conditions; the other is for thread
cancellation.

- Signal handling does not fully conform to the Posix standard,
due to the fact that threads are here distinct processes that can be
sent signals individually, so there's no notion of sending a signal
to "the" process (the collection of all threads).
More precisely, here is a summary of the standard requirements
and how they are met by the implementation

1- Synchronous signals (generated by the thread execution, e.g. SIGFPE)
are delivered to the thread that raised them.
(OK.)

2- A fatal asynchronous signal terminates all threads in the process.
(OK. The thread manager notices when a thread dies on a signal
and kills all other threads with the same signal.)

3- An asynchronous signal will be delivered to one of the threads
of the program which does not block the signal (it is unspecified which).
(No, the signal is delivered to the thread it's been sent to,
based on the pid of the thread. If that thread is currently
blocking the signal, the signal remains pending.)

4- The signal will be delivered to at most one thread.
(OK, except for signals generated from the terminal or sent to
the process group, which will be delivered to all threads.)

또, LinuxThreads Frequently Asked Questions 에서도
시그널에 대한 언급과 리눅스 쓰레드 내부구현에 관현 이야기가
잘 언급되어 있습니다.

http//pauillac.inria.fr/~xleroy/linuxthreads/faq.html#A

J. Signals and threads
J.1 When it comes to signals, what is shared between threads and what isn't?
J.2 When I send a SIGKILL to a particular thread using pthread_kill,
all my threads are killed!
J.3 I've installed a handler on a signal. Which thread executes the
handler when the signal is received?
J.3 How shall I go about mixing signals and threads in my program?
J.4 When one thread is blocked in sigwait(), other threads no
longer receive the signals sigwait() is waiting for! What happens?

K. Internals of LinuxThreads
K.1 What is the implementation model for LinuxThreads?
K.2 Have you considered other implementation models?

twopairs님께서 질문한 내용에 대한 답을 얻을려면
위에 언급한 내용을 모두 읽어보시고,.. 그래도 이해가 안되는 부분을
다시 질문해 주세요..

지금의 질문은 답을 하기전에 알려드려야 할 사항이 너무 많아서
힘드네요.. ^^ 하지만,
쓰레드에서 시그널 핸들링을 위한 문제는 쓰레드 라이브러리
개발 초부터 많은 논의가 있어서 찾아보시면 답이 있습니다.