From owner-freebsd-arch@FreeBSD.ORG Fri Jul 4 18:03:59 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 967652E3 for ; Fri, 4 Jul 2014 18:03:59 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 84EB622F4 for ; Fri, 4 Jul 2014 18:03:59 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id A931E1A3C49 for ; Fri, 4 Jul 2014 11:03:53 -0700 (PDT) Message-ID: <53B6EC87.1070700@freebsd.org> Date: Fri, 04 Jul 2014 11:03:51 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Re: callout(9) really this complicated? References: <20140704041521.GW45513@funkthat.com> In-Reply-To: <20140704041521.GW45513@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:03:59 -0000 On 7/3/14 9:15 PM, John-Mark Gurney wrote: > So, I was going to look at using callout(9) for some time delayed > actions... But upon reading the docs, a) the docs are inconsistent, > and b) the docs only talk about requirements in other section... > > Is there a better interface? If so, can we mark callout(9) deprecated? > If not, I have some questions... > > If you want callout_drain to work properly, you have to add extra code > to both your callout, and around the usage of it... > > callout_drain does not drain the callout: > However, the callout subsystem does guarantee that the callout will be > fully stopped before callout_drain() returns. > > Yet other parse of the docs say that you can depend upon the callout > being fully stopped.. I've sent email to Ian (iedowse) about why he > added this statement... > > Second, the amount of work you have to do to make sure you drain > seems pretty crazy as documented in Avoiding Race Conditions... > > It seems like if I have created a callout w/ callout_init_mtx, > that I shouldn't have to do extra work to make it work correctly... > > When calling _callout_stop_safe as callout_drain, there is no assert > that the lock is held, though it is documented as requiring it by: > The function callout_drain() is identical to callout_stop() except that > it will wait for the callout to be completed if it is already in > progress. > > Maybe we need to add an additional statement here? and assert that it > isn't locked? > > Also, I have tried to follow the code, but it's complicated, so I'm > hoping that I can get some help here. > > Thanks. > This isn't so bad, basically just think about there being another thread launching threads to service a routine, the logic to stop/drain is moderately complex but given a bit more time it should be relatively obvious what is needed to be done. As far as the docs regarding callout_drain, that makes sense, I think the docs are a bit overly verbose (perhaps someone was drinking too much coffee). In other words, with regards to callout_drain, what the docs mean is that when callout_drain() returns, there should be no further calls to the callout. Nothing more is meant. The important trick is NOT to hold a mutex or other lock during callout_drain() that the callout itself uses. This is relatively straightforward. -Alfred