On Fri, 23 Sep 2005, Vadim Lobanov wrote:
On Fri, 23 Sep 2005, Davide Libenzi wrote:
3. Wakeup
As determined by testing with userland code, the sys_tgkill() and
sys_tkill() functions currently will NOT wake up a sleeping
epoll_wait(). Effectively, this means that epoll_wait() is NOT a pthread
cancellation point. There are two potential issues with this:
- epoll_wait() meets the unofficial(?) definition of a "system call that
may block".
- epoll_wait() behaves differently from poll() and friends.
The epoll_wait() wait loop is the standard one that even poll() uses (prep
wait, make interruptible, test signals, sched timeo). So if poll() is woke
up, so should epoll_wait(). A minimal code snippet that proves poll()
behing woke up, and epoll_wait() not, would help.
Certainly. :-) See end of email for sample program.
I'm afraid you need to bug the glibc guys, since I think they wrap
sys_poll(). Try the test program below, when defining _X_, that makes it
call sys_poll() directly. It will have the same epoll_wait() behaviour.
I'm still a bit confused by how the pthread implementation fits
together. Correct me if the following is wrong, please:
Whenever the user wants to cancel a pthread, glibc eventually calls
{sys-}tgkill() upon the given thread, causing the kernel to return EINTR
to the blocking system call, in this case epoll_wait(). It is glibc's
job to catch this return value and realize that the thread is ready to be
killed, which it is not doing in the case of epoll_wait().
Or is the "current thread has been cancelled and should be killed" check
happening elsewhere / in some other way?
Please do not make me look at glibc/pthread code since I do not have time
ATM. I can only speculate on what it is happening. The sys_poll() and
sys_epoll_wait() system calls, when called directly, have the same
behaviour (like you can see in the test code snippet). They both return
EINTR to the caller. When you call glibc's poll(), the behaviour changes
and function is explicitly made a pthread cancellation point. The glibc's
epoll_wait() is not wrapped by the same code, and this makes it unable to
be pthread-canceled. Try to post to glibc the code snippet, and see if
they want to make epoll_wait() pthread-cancel enabled too.
By the way, I already brought this up on the glibc mailing list (before
I sent it to LKML), and it seems they couldn't care less.
(http://sources.redhat.com/ml/libc-alpha/2005-09/msg00071.html)
Yeah, that's Uli :)
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |