Threads and signals

HI,

HOW DO THREADS INTERACT WITH SIGNALS? IN PARTICULAR, IF I
HAVE A "MAIN"
PROCESS THREAD (THE ONE STARTED BY MAIN()) WHICH GENERATES
ITEMS FOR A
MUTEX-PROTECTED QUEUE WHICH ARE CONSUMED BY A WORKER THREAD,
AND I NEED
TO INSERT AN ITEM IN THE QUEUE FROM THE SIGNAL HANDLER, AM I
CORRECT
THAT DOING PTHREAD_MUTEX_LOCK() FROM THE SIGNAL HANDLER
COULD DEADLOCK
IF THE SIGNAL HANDLER IS EXECUTED BY ANY OF THE THREADS (AND
THE MUTEX
IS NON-RECURSIVE)?

HOW IS THIS SOLVED IN GENERAL? BY RECURSIVE MUTEXES?

Ivan Voras wrote:
> How do threads interact with signals? In particular, if
I have a "main"
> process thread (the one started by main()) which
generates items for a
> mutex-protected queue which are consumed by a worker
thread, and I need
> to insert an item in the queue from the signal handler,
am I correct
> that doing pthread_mutex_lock() from the signal handler
could deadlock
> if the signal handler is executed by any of the threads
(and the mutex
> is non-recursive)?
> 
> How is this solved in general? By recursive mutexes?

This is solved in general by not doing dangerous things in
signal 
handlers.  Signal handler functions are very restricted in
what they can 
safely do.  You really need to read Butenhof's book,
_Programming with 
POSIX Threads_; it has excellent coverage on this topic.

Jason
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On Jan 3, 2008 1:05 PM, Ivan Voras <ivorasfreebsd.org> wrote:
> Hi,
>
> How do threads interact with signals? In particular, if
I have a "main"
> process thread (the one started by main()) which
generates items for a
> mutex-protected queue which are consumed by a worker
thread, and I need
> to insert an item in the queue from the signal handler,
am I correct
> that doing pthread_mutex_lock() from the signal handler
could deadlock
> if the signal handler is executed by any of the threads
(and the mutex
> is non-recursive)?
>
> How is this solved in general? By recursive mutexes?
>

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.

 -Kip
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

* Ivan Voras <ivorasfreebsd.org> [080103 13:03] wrote:
> Hi,
> 
> How do threads interact with signals? In particular, if
I have a "main"
> process thread (the one started by main()) which
generates items for a
> mutex-protected queue which are consumed by a worker
thread, and I need
> to insert an item in the queue from the signal handler,
am I correct
> that doing pthread_mutex_lock() from the signal handler
could deadlock
> if the signal handler is executed by any of the threads
(and the mutex
> is non-recursive)?
> 
> How is this solved in general? By recursive mutexes?

You need to block/unblock signals or use sigwait.

So basically your code will look something like:

main()
{
  defer_signals();
  signal(SIGWHATEVER, &handler);
  make_threads();
  for ( ;; ) {
     do_stuff();
     undefer_signals();
     /* right here "handler" may be called */
     defer_signals();
  }
}

Another option is to have one of your threads use sigwait()
and
do the operation synchronously.

Another is to write(2) to a pipe(2) from within your signal
handler
that one of your threads is select(2)/poll(2)/kevent(2)
against,
then the selecting thread can read the byte, thereby
clearing the
event and then queue the workitem synchronously.

-- 
- Alfred Perlstein
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On 04/01/2008, Alfred Perlstein <alfredfreebsd.org> wrote:

> You need to block/unblock signals or use sigwait.
>
> So basically your code will look something like:

>   defer_signals();

Interesting approach - should I also use it to ensure only
one of the
threads gets the signal?
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

* Ivan Voras <ivorasfreebsd.org> [080104 03:23] wrote:
> On 04/01/2008, Alfred Perlstein <alfredfreebsd.org> wrote:
> 
> > You need to block/unblock signals or use sigwait.
> >
> > So basically your code will look something like:
> 
> >   defer_signals();
> 
> Interesting approach - should I also use it to ensure
only one of the
> threads gets the signal?

Certainly.

-- 
- Alfred Perlstein
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

ALFRED PERLSTEIN WROTE:
> * IVAN VORAS <IVORASFREEBSD.ORG> [080104
03:23] WROTE:
>> ON 04/01/2008, ALFRED PERLSTEIN <ALFREDFREEBSD.ORG> WROTE:
>>
>>> YOU NEED TO BLOCK/UNBLOCK SIGNALS OR USE
SIGWAIT.
>>>
>>> SO BASICALLY YOUR CODE WILL LOOK SOMETHING
LIKE:
>>>   DEFER_SIGNALS();
>> INTERESTING APPROACH - SHOULD I ALSO USE IT TO
ENSURE ONLY ONE OF THE
>> THREADS GETS THE SIGNAL?
> 
> CERTAINLY.

HMM:

:/USR/INCLUDE> MAN DEFER_SIGNALS
NO MANUAL ENTRY FOR DEFER_SIGNALS
:/USR/INCLUDE> GREP -R DEFER_SIGNALS *
-NOTHING FOUND

WHERE IS DEFER_SIGNALS() ?

* Ivan Voras <ivorasfreebsd.org> [080104 04:06] wrote:
> Alfred Perlstein wrote:
> > * Ivan Voras <ivorasfreebsd.org> [080104
03:23] wrote:
> >> On 04/01/2008, Alfred Perlstein <alfredfreebsd.org> wrote:
> >>
> >>> You need to block/unblock signals or use
sigwait.
> >>>
> >>> So basically your code will look something
like:
> >>>   defer_signals();
> >> Interesting approach - should I also use it to
ensure only one of the
> >> threads gets the signal?
> > 
> > Certainly.
> 
> Hmm:
> 
> :/usr/include> man defer_signals
> No manual entry for defer_signals
> :/usr/include> grep -r defer_signals *
> -nothing found
> 
> Where is defer_signals() ?
> 

That was psuedocode.

You need to read up on signals, look at sigaction,
pthread_sigmask,
sigprocmask and such.

-- 
- Alfred Perlstein
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"

On Thu, 3 Jan 2008, Ivan Voras wrote:

> Hi,
>
> How do threads interact with signals? In particular, if
I have a "main"
> process thread (the one started by main()) which
generates items for a
> mutex-protected queue which are consumed by a worker
thread, and I need
> to insert an item in the queue from the signal handler,
am I correct
> that doing pthread_mutex_lock() from the signal handler
could deadlock
> if the signal handler is executed by any of the threads
(and the mutex
> is non-recursive)?

Yes, you don't want to call pthread_mutex_lock() (or really
any other
non-async-signal-safe function) from the signal handler.

> How is this solved in general? By recursive mutexes?

You can use sigwait() to wait for the signal and block it in
all
other threads, or you can use a pipe and write(2) to the
pipe from
the signal handler and have another reader thread handle the
request.
I suppose there are other ways, like sem_post().

-- 
DE
_______________________________________________
freebsd-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"