This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: pthread_sigqueue{_np} ??
- To: Bharadwaj Yadavalli <bharadwaj dot yadavalli at compaq dot com>
- Subject: Re: pthread_sigqueue{_np} ??
- From: Britton <fsblk at aurora dot uaf dot edu>
- Date: Thu, 8 Feb 2001 12:19:26 -0900 (AKST)
- cc: <drepper at cygnus dot com>, <libc-alpha at sourceware dot cygnus dot com>
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? 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). 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?
Britton
> I am unaware of a "clean" way to translate thread id
> to its corresponding pid. I am not sure if ploughing
> thru' the internal thread handles is a good idea either.
>
> >From your response it appears that there is a different
> approach. Can you say a few more words about what you
> thought of when you said that it can be implemented
> outside pthreads library?
>
> Bharadwaj
>