From owner-freebsd-threads@FreeBSD.ORG Wed Oct 8 20:45:25 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55BEF106568A; Wed, 8 Oct 2008 20:45:25 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAC38FC32; Wed, 8 Oct 2008 20:45:24 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m98KOcEV060930; Wed, 8 Oct 2008 14:24:39 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m98JmXEP070814; Wed, 8 Oct 2008 13:48:33 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id m98JmXuM070811; Wed, 8 Oct 2008 13:48:33 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18669.3729.459915.769388@gromit.timing.com> Date: Wed, 8 Oct 2008 13:48:33 -0600 From: John Hein To: John Baldwin In-Reply-To: <200810081409.31822.jhb@freebsd.org> References: <18668.10465.699531.162573@gromit.timing.com> <200810081409.31822.jhb@freebsd.org> X-Mailer: VM 7.19 under Emacs 22.2.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: Daniel Eischen , freebsd-threads@freebsd.org Subject: Re: pthread_cleanup_push & pthread_cleanup_pop usage X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2008 20:45:25 -0000 John Baldwin wrote at 14:09 -0400 on Oct 8, 2008: > Don't Do That (tm). The spec explicitly states that they can be defined as > macros and that code using it needs to put them in the same block. Thanks for the responses. I like deischen's response best to work around the problem short term, but I suspect that's not very portable. And as jhb describes using it outside the same block violates the spirit of intended use. Note that the example I gave (pop off the cleanup stack in a catch block) is not our only "violation". We also push in one function and either never [explicitly] pop or possibly pop in another function. So that leaves me wondering about possible techniques for cleanup on thread cancellation or exit. Alfred touched on one method, and I see that pthread_key_create takes an optional destructor, so that sounds like a possible avenue to explore.