From owner-freebsd-arch@freebsd.org Wed May 2 15:42:42 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E06BAFAD06E for ; Wed, 2 May 2018 15:42:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ADB677E8E; Wed, 2 May 2018 15:42:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x244.google.com with SMTP id t7-v6so8655073itf.0; Wed, 02 May 2018 08:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=o/85Bhk1oENGy81CAGVx1qSrmho4L2CpKiPJ89tNtAg=; b=ZUYyThI+qLPaUD7EUEX47Vd7j3Vct6yMBCFWQgdz/fYSh6oy0AC1cXeZkXB+C/O8Qv bofxEmcSOwvwehaCkaYJazOmnbbyX8Zpn+kuSI9BRiOXpnaJYkyJ7MjaKjgtx9s3EL6o pLUBFw+1f3eWIBZfBzjmxFmO95d3I0UbEMYvhWOG71tcNzQ4DIUocijinHruenDNu8ru OPx9bc1Y/wL31ejM/S0EMW9nEsvO2NwHRhAuMnRXb2XfSO/jBfCMgugO2Y1pXc+jTlC/ 3N16zS9bIbP+bERpuV5snXa608pjsjnDzkZyiD5n+MslxkwykgfA/uQnvgVe+u/zobai twSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=o/85Bhk1oENGy81CAGVx1qSrmho4L2CpKiPJ89tNtAg=; b=RBZEe9GoRbbqj7HIy5jQS7DxgTcrPyMDkffmNUuCOYjT/eYHoypIvBE5aTaPW1+j5j QXWsiv+NEXD67JgPf8QmrF5B8xczuOSGns0QhdvLRH5GPABCw2/9b4quOcszeUmJf/Oh oKcGulWzpmcAq1B+U4ixn9k7aLUCPDzTWKMIFETyI+Qm2l3YAP7J9x70/6ZwtxLHFbYG o8yLRc2OVBpjtODn4sH5JxbvQyMrBLMm6VNWK0xl9DjjOOfXaNsP9yuE+2m2WhDMuUTB 7HHmBmIGgi99Q99jhPy40wqXsi0UT/5vaoCOjXLd93aGt8JStZ8rFActFMxA8gyyv/Oj bG8w== X-Gm-Message-State: ALQs6tCSSFw9GxapS78LQbV/WfqIfN/cR6nTcKJelNwB42HlaxpoGGmF 4PIUeauLUP90DkbngQiUu8AwMQ== X-Google-Smtp-Source: AB8JxZrajLGFpkpIP8tTshZhW087xSxOgB4ZgTjZleU8qH52ZHF0gtg0kD8MlqiSukdr7vlwhuoeyg== X-Received: by 2002:a24:1acc:: with SMTP id 195-v6mr21037267iti.48.1525275760537; Wed, 02 May 2018 08:42:40 -0700 (PDT) Received: from raichu (toroon0560w-lp130-04-184-145-252-74.dsl.bell.ca. [184.145.252.74]) by smtp.gmail.com with ESMTPSA id k130-v6sm5993029itb.0.2018.05.02.08.42.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 08:42:39 -0700 (PDT) Sender: Mark Johnston Date: Wed, 2 May 2018 11:42:37 -0400 From: Mark Johnston To: Ian Lepore Cc: freebsd-arch@FreeBSD.org Subject: Re: callout_stop() return value Message-ID: <20180502154237.GB24397@raichu> References: <20180502152024.GA24397@raichu> <1525275297.57768.202.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1525275297.57768.202.camel@freebsd.org> User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 15:42:42 -0000 On Wed, May 02, 2018 at 09:34:57AM -0600, Ian Lepore wrote: > On Wed, 2018-05-02 at 11:20 -0400, Mark Johnston wrote: > > Hi, > > > > We have a few pieces of code that follow a pattern: a thread > > allocates a > > resource and schedules a callout. The callout handler releases the > > resource and never reschedules itself. In the common case, a thread > > will cancel the callout before it executes. To know whether it must > > release the resource associated with the callout, this thread must > > know > > whether the pending callout was cancelled. > > > > It seems to me a better solution would be to track the state / lifetime > of the resource separately rather than trying to infer the state of the > resource from the state of the callout as viewed through a semi-opaque > interface. > > If the original thread that schedules the callout keeps enough > information about the resource to free it after cancelling, then it is > already maintaining some kind of sideband info about the resource, even > if it's just a pointer to be freed. Couldn't the callout routine > manipulate this resource tracking info (null out the pointer or set a > bool or whatever), then after cancelling you don't really care whether > the callout ran or not, you just examine the pointer/bool/whatever and > free or not based on that. I'd considered that. It's not quite as elegant a solution as you suggest, since in my case the resource is embedded in an opaque structure, so I need to add an extra field beside the callout to track state that's already tracked by the callout subsystem. That plus the fact that we have multiple instances of this bug make me want to fix it in a general way, though I recognize that the callout API is already overly complicated.