On 8/20/06, Anthony Howe <[EMAIL PROTECTED]> wrote:
I too am having problems using sigaltstack() in pthreads application.
Otto's quote earlier this year of the Single Unix Specification
http://www.sigmasoft.com/~openbsd/archives/html/openbsd-bugs/2006-03/msg00129.html
"Use of this function by library threads that are not bound to
kernel-scheduled entities results in undefined behavior."
Note that it says library threads.
http://www.unix.org/single_unix_specification/
does not make sense to me. Reading from the "man 3 pthreads":
Thread stacks
Each thread has (or should have) a different stack,
whether it be provided by a user attribute, or provided
automatically by the system. If a thread overflows its
stack, unpredictable results may occur. System-allocated
stacks (including that of the initial thread) are
typically allocated in such a way that a SIGSEGV signal is
delivered to the process when a stack overflows.
Signals handlers are normally run on the stack of the
currently executing thread. Hence, if you want to handle
the SIGSEGV signal, you should make use of sigaltstack(2)
or sigprocmask(2).
How are you suppose to handle SIGSEGV when a thread blows its stack, if
you cannot set the alternate stack for the SIGSEGV handler in the first
place?
I don't what happens when a thread other than the main blows its
stack. But anyway, if you setup the alternate stack from the ain
thread you should have no problems. (It may be true for other threads
but I don't know.)
There appears to be a contradiction here in the documentation. Are
pthreads not kernel scheduled entities?
The current pthreads implementation is all in userland.
--
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/
--
"What is your function in life?" - Killer
