From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 15:48:39 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABF616A5AB for ; Thu, 3 Jan 2008 15:48:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 99DA413C4CE for ; Thu, 3 Jan 2008 15:48:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4131959fgg.35 for ; Thu, 03 Jan 2008 07:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=gaebBOGftdSZwl0ZjfQcB1g8LUk5X9es14amhi7fnV8=; b=caH611FuaGOnQ8+0CmXFP/DnZRYuV5fowjTd7knlwoZkq4GJDl32ACRc1KiUn9YVHr71ctV/1jrsE7TM75d+K5nZKaNcR1pEHfarYRzkujYATw6am2wijF1mJPM2K3K/bdWxjUxxCZSRV/ytJ0FnOCGMDPb8FUdajn4zFagl+Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=N9oWBzKZuU/THEzvJUeCDqBUogC6OILD2rOxyGWV2eOitEiFmMYtCi08C2VN25U3QKuGUvzxvJJGPbFfbktlOWcu3DU3B0uVA9oo5/ZVcFplyzgaOkV/lZGaSmgRPqe9p7837sMmYO6SU6kSUagyOCPuLNshJmWMLCJdUmSl1RA= Received: by 10.86.95.20 with SMTP id s20mr15727182fgb.46.1199375317170; Thu, 03 Jan 2008 07:48:37 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 3 Jan 2008 07:48:37 -0800 (PST) Message-ID: <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> Date: Thu, 3 Jan 2008 16:48:37 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <2296.1199319966@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477C2A8A.8090604@freebsd.org> <2296.1199319966@critter.freebsd.dk> X-Google-Sender-Auth: fe728188f4acfb7d Cc: arch@freebsd.org, Robert Watson , Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 15:48:39 -0000 2008/1/3, Poul-Henning Kamp : > In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: > > >>>>> I fear we have to go for the latter. Getting a non-sleeping callout > >>>>> drain seems to be non-trivial. > >>>> There is a crucial difference between "non-sleeping" and "not sleeping > >>>> on my lock" that you should be very careful about in this context. > >>>> > >>>> Which is your requirement ? > >>> Calling timeout_drain() must not sleep and not drop the lock in this > >>> context (while making any pending timeout go away forever). > >> > >> Ok, so if the timeouts callback function is running you propose to > >> do what ? spin until it returns ? > > > >As long as the spinning is bounded [...] I don't have a perfect solution > >handy. That's why I try to state the requirement and hope the timeout > >gurus can work out how to do it. ;-) > > It's all Alan Turings fault :-) > > You can't have that, it's that simple. > > What I'm proposing is that your thread will sleep on a plain, but > unrelated mutex (internal to the timeout code) until the function > comes back. > > Based on your description above, you won't be able to tell the > any difference between this and what you wish for. This will be hardly feasible. Internal callout subsystem locks probabilly need to be spinlocks in order to avoid lock mismatches against sleepable locks. callout_drain() so far works good just because it assumes no locks held while sleeping. A solution for this is not trivial and needs to be better through. If someone can propose a real and working prototype the discussion would be more productive as, really, current callout code has a lot of little constraints not trivial if not analyzed in practice. Attilio -- Peace can only be achieved by understanding - A. Einstein