Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Jan 2008 00:42:15 +0100 (CET)
From:      Jan Pechanec <jp@devnull.cz>
To:        Kip Macy <kip.macy@gmail.com>
Cc:        Ivan Voras <ivoras@freebsd.org>, freebsd-threads@freebsd.org
Subject:   Re: Threads and signals
Message-ID:  <20080104003530.F93027@shark.devnull.cz>
In-Reply-To: <b1fa29170801031438m5d0c47cdtbef5363095570b11@mail.gmail.com>
References:  <fljin9$crb$1@ger.gmane.org> <b1fa29170801031438m5d0c47cdtbef5363095570b11@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jan 2008, Kip Macy wrote:

>Very few functions are async signal safe. As a general rule you should
>avoid doing things from the signal handler itself. On some operating
>systems such as Solaris, most things will "just work". However, that
>can't be relied upon across platforms.

	hi Kip, just to add, you can use pthread_mutex_lock() there from 
signal handlers since they are MT-safe but if you use it on the same mutex 
then you are still screwed. Well, it will probably work since be default 
mutexes on Solaris are of type PTHREAD_MUTEX_NORMAL but as you say - it 
depends on the platform. Locking the same mutex twice is plain wrong. By the 
way, the default type on FreeBSD is PTHREAD_MUTEX_ERRORCHECK.

	very probably the only reasonable way how to work with signals with 
threads is to mask all threads but one and to use sigwait(2) there. Butenhof 
has it all, as already said.

	J.

-- 
Jan Pechanec <jp (at) devnull (dot) cz>
http://www.devnull.cz



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080104003530.F93027>