Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966906AbXEGVBB (ORCPT ); Mon, 7 May 2007 17:01:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S966630AbXEGVBA (ORCPT ); Mon, 7 May 2007 17:01:00 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]:10639 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966624AbXEGVA7 (ORCPT ); Mon, 7 May 2007 17:00:59 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K7dlYOXTkfY031qW7GI/XK438mZI1PsBICh5q7knSixkF01EY/j2hBnYWcSXOdFysQpFJVwtrNwrSJoiSh7KbiNFoREhWyN8JJvTRQ9oWcQmZu1Y4KPs7Mg3uMbzyTIKbklEUFy9eRKBJKs8AQ2f2jWhLHbT7BQXfGTFmzMdWeo= Message-ID: Date: Mon, 7 May 2007 14:00:58 -0700 From: "Ulrich Drepper" To: "Davi Arnaut" Subject: Re: [PATCH] rfc: threaded epoll_wait thundering herd Cc: "Davide Libenzi" , "Andrew Morton" , "Linus Torvalds" , "Linux Kernel Mailing List" In-Reply-To: <463CFA37.3020809@haxent.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070504225730.490334000@haxent.com.br> <463BC3CA.6050109@haxent.com.br> <463CFA37.3020809@haxent.com.br> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1787 Lines: 37 On 5/5/07, Davi Arnaut wrote: > A google search turns up a few users. It also addresses some complaints > from Drepper. There is a huge problem with this approach and we're back at the inadequate interface. select/poll/epoll are thread cancellation points. I.e., the thread can be canceled before returning to the user. If this cancellation happens between the kernel deciding to give this thread the event (and no other thread) and the thread testing for cancellation in the libc wrapper around the syscall, then the event is lost and the process(es) might hang. With kevent we in the end fixed the problem by requiring that part of the cancellation handling the thread tries to wake up another thread waiting for the event queue. This is easily possible since the event data is in the shared memory segment and it's just purely the thread wakeup that is needed. To make something like this work for poll you'd have to push back the revents fields of the result back to the kernel which might then cause another thread to be woken up. I find this too ugly to consider. You guys will not believe this but I really thought all these things through before writing the OLS paper. poll cannot be salvaged. There is another thing about this selective wakeup: do I assume it correctly that if more than one file descriptor is reported ready more than one thread is woken? I think nothing else can be justified. Will in this case both threads get the same set of descriptors reported or will they see disjunct sets? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/