[gccsdk] UnixLib, Signals & Threading
lists at snowstone.org.uk
Wed Jul 9 14:22:00 PDT 2008
In message <8b4057bc4f.ajw498 at caramel.cp15.org>, Alex Waugh wrote:
> Adam <lists at snowstone.org.uk> wrote:
> > In message <9b8757bb4f.ajw498 at caramel.cp15.org>, Alex Waugh wrote:
> > > Adam <lists at snowstone.org.uk> wrote:
> > > > I'm trying to get my head around handling signals in a threaded
> > > > app. However, I keep just getting a stack backtrace written to
> > > > stderr. As far as I can tell my signal handler never gets a look
> > > > in.
> > >
> > > Signals should execute in the context of the thread that caused
> > > them,
When you say "should", does that mean in this case the pthreads
behaviour in UnixLib does not meet the POSIX specification? Are there
any examples where the UnixLib behaviour deviates from POSIX?
> > > however they currently execute in the global context which makes
> > > it hard to implement sigwait correctly as the context switcher
> > > wouldn't know which thread to wake up on a signal (so it doesn't
> > > bother). The only way to send a signal that sigwait will notice is
> > > to use pthread_kill().
> > Thanks a lot for that - it's good to at least know it won't work in
> > principle.
> > What, in that case, is the recommeded way to deal with signals in a
> > multi-threaded app? A disappearing app + stackdump-to-stderr is not
> > a total disaster while debugging, but it's not ideal for a released
> > program.
> The normal ANSI signal handling functions should work fine, provided
> you don't call any pthread functions from them or expect them to be
> context switched.
OK, thanks. All the stuff I've read about signals and threads has said
to use the sigwait() functionality in preference to the ANSI signal
handling stuff. Perhaps the UnixLib implementation lends itself to a
different approach though. I'll have a further think about it.
Adam Richardson Carpe Diem
More information about the gcc