This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: pthread_sigqueue{_np} ??
- To: fsblk at aurora dot uaf dot edu (Britton)
- Subject: Re: pthread_sigqueue{_np} ??
- From: Bharadwaj Yadavalli <sby at ives dot lkg dot dec dot com>
- Date: Thu, 8 Feb 2001 16:52:11 -0500 (EST)
- Cc: libc-alpha at sourceware dot cygnus dot com
- Reply-To: Bharadwaj Yadavalli <bharadwaj dot yadavalli at compaq dot com>
From : Britton <fsblk@aurora.uaf.edu>
Date : Thu Feb 8 16:19:26 2001
On Thu, 8 Feb 2001, Bharadwaj Yadavalli wrote:
> From : Ulrich Drepper <drepper@redhat.com>
> Date : Thu Feb 8 13:01:31 2001
>
> No. Since you can easily implement it yourself there
> is no need to introduce more incompatible functionality.
>
> I would like to queue a (RT) signal to a thread by TID.
Why do you want to do this?
I need to stop the threads in a JVM (that I am porting to
Linux) to do things like garbage collection. Basically I
need to suspend and resume a given thread for this
purpose. I'd like the suspend/resume signals to be queued
rather than encountering a possible signal "merge" by using
kill.
If your program is getting asynchronous
signals from some outside source, they have to address the process as a
whole (and in LinuxThreads will presumably go to your initial thread,
since it has the PID by which outside programs know your process) and you
can handle them from there with the pthread synch calls (by setting a flag
in the handler).
Signals are not being sent from an outside source in my case.
I don't know of any reason to explicitly use signals for
intra-process communication between threads, I believe the
pthread calls provide everything you can get from queued RT
signals?
I must be missing something here and that's exactly what I
am asking for. All I want is to _queue_ a signal to a thread
running in the current "process". After talking to some one
who knows about POSIX I came to an understanding that
pthread_sigqueue() might be missing. I was also advised that
all pthread_* calls are async-signal unsafe and should not be
used in a signal handler. If I am mistaken please let me know
where. I'd really appreciate it.
Bharadwaj