From owner-freebsd-arch@FreeBSD.ORG Fri Jul 4 04:15:23 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 44D79B78 for ; Fri, 4 Jul 2014 04:15:23 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C09D29F6 for ; Fri, 4 Jul 2014 04:15:22 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s644FMYI000376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jul 2014 21:15:22 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s644FMZ6000375 for arch@FreeBSD.org; Thu, 3 Jul 2014 21:15:22 -0700 (PDT) (envelope-from jmg) Date: Thu, 3 Jul 2014 21:15:22 -0700 From: John-Mark Gurney To: arch@FreeBSD.org Subject: callout(9) really this complicated? Message-ID: <20140704041521.GW45513@funkthat.com> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 03 Jul 2014 21:15:22 -0700 (PDT) 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 04:15:23 -0000 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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."