This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: [greg@surety.com] libc/1320: pthread_cond_timedwait returns EINTR in multithreaded processes when gdb is attached to them
- To: aj at arthur dot rhein-neckar dot de, schwab at suse dot de
- Subject: Re: [greg@surety.com] libc/1320: pthread_cond_timedwait returns EINTR in multithreaded processes when gdb is attached to them
- From: Kevin_Hendricks <khendricks at admin dot ivey dot uwo dot ca>
- Date: Fri, 24 Sep 1999 13:48:40 -0400 (EDT)
- Cc: libc-alpha at sourceware dot cygnus dot com, greg at surety dot com, gdb at sourceware dot cygnus dot com
- Reply-To: Kevin_Hendricks <khendricks at admin dot ivey dot uwo dot ca>
Hi,
>SUS2 says that pthread_cond_timedwait must never return with EINTR. If it
>is interrupted it must either continue waiting or return zero. I think
>continue waiting is the desired action.
>
>I'm not sure whether this is the right way to fix the bug.
Are you sure you want to do this?
Before we started using pthread_cancel and longjmping out of the cleanup handler
clean-up handler, the JDK (Blackdown) used to use a signal to interrupt threads
waiting in condvar_timed_wait and relied on the EINTR to do the trick.
The problem with this approach was that it could miss signals, but people may
still want to be able to break out of timed_waits (you can implement
condvar_wait with condvar_timed_wait and break out of both with a signal).
What does the pthreads spec say about condvar_timed_wait and returning EINTR?
My 2 cents,
Kevin