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: Thu, 20 Sep 2007 11:36:33 -0400 Message-ID: <2bc5f8210709200836i1267bcc8qa066b4d27f2c3e2@mail.gmail.com> References: <2bc5f8210709200730q61d7973ft8d1da14889efb2f1@mail.gmail.com> <87abrhl604.fsf@laas.fr> 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 1190302614 32071 80.91.229.12 (20 Sep 2007 15:36:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2007 15:36:54 +0000 (UTC) To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Sep 20 17:36:53 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 1IYO53-0004xp-0P for guile-devel@m.gmane.org; Thu, 20 Sep 2007 17:36:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IYO51-0000JL-4x for guile-devel@m.gmane.org; Thu, 20 Sep 2007 11:36:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IYO4y-0000JG-Ku for guile-devel@gnu.org; Thu, 20 Sep 2007 11:36:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IYO4x-0000J1-5B for guile-devel@gnu.org; Thu, 20 Sep 2007 11:36:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IYO4w-0000Iy-VO for guile-devel@gnu.org; Thu, 20 Sep 2007 11:36:35 -0400 Original-Received: from fk-out-0910.google.com ([209.85.128.187]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IYO4w-0001jY-JC for guile-devel@gnu.org; Thu, 20 Sep 2007 11:36:34 -0400 Original-Received: by fk-out-0910.google.com with SMTP id 19so650130fkr for ; Thu, 20 Sep 2007 08:36:33 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l1OPW8dJG0FM5F3iykCHeLMc5V8brE05j17F4jKpg9k=; b=cXiH49FAxwvIWJ9ihWY3H1oT/B5d3cYkNdOb4TU9lUepiXAo2vLEHjrU33ZCxBFUrsjUhqe9Mk70LgCeZB3XdFzpVnKRrT0zcPAnJAn7WnEgqTaEUh/JDHx2lcKgWdZheQ3jqraWA7S4nAKs38aNLRRCj2M1evRRi9f0GjHN51w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V6LfS49c1npsM+qRAZGMZG2ppNWTDrFxpio94s5BlKUxiY8Jv7/U1NatOEWcmYNJEnhdGd/mj9nkZEDTzYDQ5ebMfG2QAudyJylEz8Rbdp0+bFg2ecUqDjj07dWTeLHCRyj1BCM5abzNQmNneheK1BKpQZ+ASrEXtSlnqEZQ0/c= Original-Received: by 10.82.178.11 with SMTP id a11mr2858433buf.1190302593135; Thu, 20 Sep 2007 08:36:33 -0700 (PDT) Original-Received: by 10.82.175.11 with HTTP; Thu, 20 Sep 2007 08:36:33 -0700 (PDT) In-Reply-To: <87abrhl604.fsf@laas.fr> 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:6805 Archived-At: > Would it be possible to defer execution of the Scheme code (cleanup > handlers) to after the C cleanup handler has been called? > > I.e., the C handler would push the Scheme handlers to a list that would > be eventually executed, when Guile is back into a "clean", regular > state. Yeah, that would be fine -- except that after the thread is signaled for cancellation, it'll never go back into a regular state. That is, I think the next thing that happens is that the thread-local exit handlers (on_thread_exit in threads.c) get called -- and I don't think that code evaluates queued asyncs (please let me know if it actually does!). And any queued asyncs would have to be evaluated within that thread (and in order), because people are going to want to do things that have to be done from within a particular thread, like unlock mutexes. > I'd prefer thunks as well, it looks more Schemey. I agree -- and makes things way easier if it turns out it's possible to do this with asyncs. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel