This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: changes in pthread signal handling to achieve posix compliance?


On Tue, 29 Aug 2000, Hendricks, Kevin wrote:

> Date: Tue, 29 Aug 2000 10:05:41 -0400
> From: "Hendricks, Kevin" <khendricks@ivey.uwo.ca>
> To: Kaz Kylheku <kaz@ashi.footprints.net>
> Cc: libc-alpha@sourceware.cygnus.com
> Subject: Re: changes in pthread signal handling to achieve posix compliance?
> 
> Hi,
> 
> >> Will there still be an option to send a thread specific signal?
> >
> >There will have to be, because otherwise what would pthread_kill() do?
> 
> Good point! I guess I should be more concerned about asynchronous external
> signals that need to be handled by applications (sigquit, sigchild of
> another thread? etc)?
> 
> More specifically, will you still need/use a manager thread in your
> pthreads implementation?  Right now you also use the manager thread to make
> your sem_post asynch signal safe.  If the goal of these changes is to speed
> up thread creation, what changes will occur and when?

The manager was introduced because threads needed to hang off a parent to
clone() them and to call waitpid().  It has become useful for other reasons.
For example, the thread manager plays a role in coordinating process shutdown,
and the async-safe sem_post that you mention.

It's unlikely that the manager thread can be removed, and it doesn't sound like
the signal related work is going to provide any kernel functionality that could
replace the manager. (Also, the GDB maintainers would probably kill us).

> I guess I am asking, is this something I need to worry about for glibc 2.2
> and kernel 2.4 or would changes like this be restricted to some glibc 2.2.X
> or higher release?

Any experimental work done by kernel 2.4 would have to be carefully coded
around; the library can't assume that it's running on a patched 2.4 kernel with
some neat new signal handling. It would have to do some run-time detection,
similar to what has been done, for example, to detect whether real time signals
are supported or whether SMP is present.

Someone has to look at the new signal handling and think about how to integrate
it with minimal impact.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]