From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Julian Graham" Newsgroups: gmane.lisp.guile.devel Subject: Re: thread cancellation, take 2 Date: Sun, 23 Sep 2007 14:39:17 -0400 Message-ID: <2bc5f8210709231139x4ed56fc4q9ae28afdb707457b@mail.gmail.com> References: <2bc5f8210709200730q61d7973ft8d1da14889efb2f1@mail.gmail.com> <87abrhl604.fsf@laas.fr> <2bc5f8210709200836i1267bcc8qa066b4d27f2c3e2@mail.gmail.com> <2bc5f8210709222216rf7aa8ednd380fa8db2975073@mail.gmail.com> <87vea1oe70.fsf@chbouib.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190572777 25784 80.91.229.12 (23 Sep 2007 18:39:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 23 Sep 2007 18:39:37 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 23 20:39:31 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IZWMZ-0006wN-FS for guile-devel@m.gmane.org; Sun, 23 Sep 2007 20:39:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZWMW-0001Rr-UZ for guile-devel@m.gmane.org; Sun, 23 Sep 2007 14:39:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZWMT-0001Qp-S0 for guile-devel@gnu.org; Sun, 23 Sep 2007 14:39:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZWMR-0001QZ-OC for guile-devel@gnu.org; Sun, 23 Sep 2007 14:39:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZWMR-0001QW-LC for guile-devel@gnu.org; Sun, 23 Sep 2007 14:39:19 -0400 Original-Received: from fk-out-0910.google.com ([209.85.128.190]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IZWMQ-0003og-Rj for guile-devel@gnu.org; Sun, 23 Sep 2007 14:39:19 -0400 Original-Received: by fk-out-0910.google.com with SMTP id 19so1604857fkr for ; Sun, 23 Sep 2007 11:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UyifmOmlmpAKiuprthqN36IpKrhRfH94a8KDKBNd/n0=; b=IrHa5I+cFnmHGPOuh2fRoweQqmBwmPHDUmwNi1N2Tb0dXcU60/YFGmylI/zeRkBeJGbUqVubK5CKr09Zdl/DVTtS12vR0KovhUch6Zf3LULhoKGCMConbGJYwKF6WAOqZeyImz+d3pJb6AYRd2f49dun1YP7mw6oSuROBWZVi9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q0NGJ3tQHFJZaPZpfJvQ9GvVlXD4BaLpyghSoOGcdt3zeKNi93bVgHSysi5nJvEyXAjQwD5GQjJM0LmgjMBd9CnkNzkT2r5P5/lvLTjNRX0jL/p51HUC+FBYDyPZLRnQrU/r19+aSHUZ5AA38nJEQcAAY54iSEQfCjqvzPxTB/0= Original-Received: by 10.82.126.5 with SMTP id y5mr5163249buc.1190572757463; Sun, 23 Sep 2007 11:39:17 -0700 (PDT) Original-Received: by 10.82.175.11 with HTTP; Sun, 23 Sep 2007 11:39:17 -0700 (PDT) In-Reply-To: <87vea1oe70.fsf@chbouib.org> Content-Disposition: inline X-Detected-Kernel: Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6810 Archived-At: > Thinking a bit more about it, maybe we could let users handle the list > of handlers if needed. That is, we'd have just > `set-thread-cleanup-procedure!' (a two-argument procedure whose first > arg is a thread) and `thread-cleanup-procedure' (a one-argument > procedure); users who have cleanup code spread over several procedure > would provide a procedure that iterates over such pieces of code. That > would keep Guile's built-in mechanisms minimal. > > What do you think? Well, in the use case for the native pthread_cancel implementation, it makes a lot of sense to treat the handler list as a stack. That is, you have something like: [LOCK MUTEX 1] pthread_cleanup_push([UNLOCK MUTEX 1]) [ ...CODE CONTAINING CANCELLATION POINTS... ] [LOCK MUTEX 2] pthread_cleanup_push([UNLOCK MUTEX 2]) [ ... ] pthread_cleanup_pop() [UNLOCK MUTEX 2] [ ... ] pthread_cleanup_pop() [UNLOCK MUTEX 1] What's useful about this is that you can have several resources at different levels of nesting that need to be cleaned up at cancellation time, but you only need to worry about pushing and popping handlers within your own scope. If people feel that managing the entire list at once is more Scheme-y, though, I can change it. > First, you'll need to assign copyright to the FSF so that we can > incorporate your changes (I'll send you the relevant stuff off-line). > Then, you need to make sure your code follows the GNU Standards as much > as possible (a few comments follow). Also, please add a few test cases > to `threads.test' that exercise the new API. Great -- I'll deal with the paperwork, add tests, and clean up the code as you've suggested. I'll send the revisions to you offline, if that's okay. Thanks, Julian _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel