Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755215AbXIZHQv (ORCPT ); Wed, 26 Sep 2007 03:16:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751011AbXIZHQo (ORCPT ); Wed, 26 Sep 2007 03:16:44 -0400 Received: from mail.gmx.net ([213.165.64.20]:46908 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750773AbXIZHQn (ORCPT ); Wed, 26 Sep 2007 03:16:43 -0400 X-Authenticated: #24879014 X-Provags-ID: V01U2FsdGVkX18jJu8EgXIjCgGEAuYo1834uP0Cs8DGWWjGsaI73Y KSxefkOKE/5Dgp Message-ID: <46FA06C6.5090703@gmx.net> Date: Wed, 26 Sep 2007 09:14:14 +0200 From: Michael Kerrisk User-Agent: Thunderbird 1.5.0.8 (X11/20060911) MIME-Version: 1.0 To: Davide Libenzi CC: Jonathan Corbet , Thomas Gleixner , Andrew Morton , Linus Torvalds , Linux Kernel Mailing List Subject: Re: [patch 2/4] new timerfd API v2 - new timerfd API References: <12492.1190738426@lwn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 44 Davide Libenzi wrote: > On Tue, 25 Sep 2007, Jonathan Corbet wrote: > >> One quick question: >> >>> Like the previous timerfd API implementation, read(2) and poll(2) are supported >>> (with the same interface). >> Looking at that interface, it appears that a process doing a read() on a >> timerfd with no timer set will block for a very long time. It's an >> obvious "don't do that" situation, but perhaps we could help an >> occasional developer get a clue by returning something like -EINVAL when >> the timer has not been set? > > That is the same as you try to read once more after an expired timer. You > won't wake up until the next timer event will show up. That is, after at > most TP time for periodic timers, or after the time the next > timerfd_settime() will setup. > I'd like to keep the "timerfd not set yet" and the "timerfd already > expired and not re-armed" acting the same way. That is, wait till next > event happen (unless O_NONBLOCK of course). Yes. The timer_settime() and read() might for example be done in separate threads, and it would make sense for the read() to block until the timer has been armed. Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages/ read the HOWTOHELP file and grep the source files for 'FIXME'. - 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/