Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967737AbXEHD5V (ORCPT ); Mon, 7 May 2007 23:57:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S967721AbXEHD5R (ORCPT ); Mon, 7 May 2007 23:57:17 -0400 Received: from smtpout.mac.com ([17.250.248.171]:59055 "EHLO smtpout.mac.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967720AbXEHD5R (ORCPT ); Mon, 7 May 2007 23:57:17 -0400 In-Reply-To: References: <20070504225730.490334000@haxent.com.br> <463BC3CA.6050109@haxent.com.br> <463CFA37.3020809@haxent.com.br> <463F9B68.305@haxent.com.br> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Davide Libenzi , Davi Arnaut , Andrew Morton , Linus Torvalds , Linux Kernel Mailing List Content-Transfer-Encoding: 7bit From: Kyle Moffett Subject: Re: [PATCH] rfc: threaded epoll_wait thundering herd Date: Mon, 7 May 2007 23:56:40 -0400 To: Ulrich Drepper X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2326 Lines: 56 On May 07, 2007, at 22:49:04, Ulrich Drepper wrote: > On 5/7/07, Davide Libenzi wrote: >> read(2) is a cancellation point too. So if the fine userspace code >> issues a random pthread_cancel() to a thread handling that, data >> is lost together with the session that thread was handling. > > This is absolutely not comparable. When read/write is canceled no > data is lost. Some other thread might have to pick up the slack > but that's it. Uhh, how can you claim "no data is lost" in this scenario: A bunch of threads shares a common fd and fpos, reading fixed-size records: thread1: read(myfd, per_thread_buf, 512); thread2: pthread_cancel(thread1); thread3: read(myfd, per_thread_buf, 512); This is *exactly* analogous to the epoll() scenario: A bunch of threads are attempting to get data (either events or records) from a given object. If thread1 gets cancelled after the completion of its read() syscall then the file position will have been advanced but the data in the per-thread buffer will be discarded. The third thread won't (reliably) get the same data as thread1. It might get it randomly on occasion if file position updates race, but you can't rely on that behavior. Here's how you make both of those models safe against thread cancellation (assuming, of course, that process_one_buf has no cancellation points until after it saves the buffer state somewhere): char per_thread_buf[512]; pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL); pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); while (read(fd, per_thread_buf, 512) == 512) { pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL); process_one_buffer(per_thread_buf); pthread_testcancel(); pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); } pthread_exit(NULL); Look how trivial that is! Isn't it fun? Of course, once you look at it this way you could do the same verbose crap that pthread_cancel/ pthread_setcancelstate/pthread_testcancel are doing with a simple int protected by a pthread_mutex. Cheers, Kyle Moffett - 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/