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: Mon, 24 Sep 2007 16:17:21 -0400 Message-ID: <2bc5f8210709241317q211d8645qc27cdd69b47efef8@mail.gmail.com> References: <2bc5f8210709200730q61d7973ft8d1da14889efb2f1@mail.gmail.com> <87abrhl604.fsf@laas.fr> <2bc5f8210709200836i1267bcc8qa066b4d27f2c3e2@mail.gmail.com> <2bc5f8210709222216rf7aa8ednd380fa8db2975073@mail.gmail.com> <87vea1oe70.fsf@chbouib.org> <2bc5f8210709231139x4ed56fc4q9ae28afdb707457b@mail.gmail.com> <87k5qg2ssf.fsf@laas.fr> <2bc5f8210709240839k3069f572ne54d10f44680671@mail.gmail.com> 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 1190665059 16805 80.91.229.12 (24 Sep 2007 20:17:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2007 20:17:39 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Sep 24 22:17:34 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 1IZuN3-0001pH-25 for guile-devel@m.gmane.org; Mon, 24 Sep 2007 22:17:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZuN0-0008RS-3S for guile-devel@m.gmane.org; Mon, 24 Sep 2007 16:17:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZuMy-0008RD-0w for guile-devel@gnu.org; Mon, 24 Sep 2007 16:17:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZuMv-0008Qt-H1 for guile-devel@gnu.org; Mon, 24 Sep 2007 16:17:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZuMv-0008Qq-EW for guile-devel@gnu.org; Mon, 24 Sep 2007 16:17:25 -0400 Original-Received: from fk-out-0910.google.com ([209.85.128.191]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IZuMv-0007OG-2v for guile-devel@gnu.org; Mon, 24 Sep 2007 16:17:25 -0400 Original-Received: by fk-out-0910.google.com with SMTP id 19so2032040fkr for ; Mon, 24 Sep 2007 13:17:24 -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=e7m/+ic0bjq1a5uiqsEBGNIy8uRWNussqaH9Rs0YTBM=; b=HgX3e2Rpp4fTVX/eZj9PUIqa3fhunOHNVV690aL9/4Hc2Hkrghjc0YAwxU50iGFnLQqhifTKvFLuK/1z3fIApZ5d7yyfC/vUiAb2sgPnPNtlc0O5Zfaq8YyiEl/CgYgTt7U53+vgUTUAD0u26gAj5Sdi29K46rkLg0HBayqhUCk= 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=lXfNTSccfPknUBJt+Dub+seUWj0EM1f2fOxCy3P06Wp6Rk2STqxFpcdH+hfOFPTY79Z6phDxkkIu+WOCOfXeLLcQJSczTfaAyxflFOWwcavMPrdwUelhKrTvqlF3APTqVXdPUbQhgqc5npE4+VlR1HfvsozDegYNgKXBiPZjlw8= Original-Received: by 10.82.106.14 with SMTP id e14mr6373809buc.1190665041969; Mon, 24 Sep 2007 13:17:21 -0700 (PDT) Original-Received: by 10.82.175.11 with HTTP; Mon, 24 Sep 2007 13:17:21 -0700 (PDT) In-Reply-To: <2bc5f8210709240839k3069f572ne54d10f44680671@mail.gmail.com> 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:6813 Archived-At: On a related note, if it's okay with everyone, I'd like to add a thread-exit function in the next revision of this patch -- we're just so close to SRFI-18 compatibility, and that would take us the last few steps, I think. Unfortunately, it doesn't seem like calling pthread_exit doesn't seem to do the trick, at least not in the main REPL thread -- it puts the process into a zombie state. It works in threads spawned by the REPL, and it works when you call it in such a way that the REPL doesn't get started up (e.g., guile -c "(exit-thread)"). I suspect this has everything to do with the signal delivery thread, but I'm struggling with the rest. Why would the fact that the signal delivery thread is left listening on a closed pipe make the process into a zombie? Exiting the entire process seems to work, so I could check to see whether the calling thread is the only active thread and then call exit(thread->result) if it is, but that's rather inelegant. (Does it even make sense to let people exit the REPL thread?) Maybe we should mark certain special threads internally as being, for example, the REPL or the signal delivery thread, etc. Can someone shed some light? I feel stupid. On 9/24/07, Julian Graham wrote: > > I find it more elegant to use closures to that end. I.e., when > > installing a handler, you'd write something like this: > > > > (let ((cleanup (thread-cleanup-procedure (current-thread)))) > > (set-thread-cleanup-procedure! (current-thread) > > (lambda () > > ;; invoke previous handler > > (if (procedure? cleanup) > > (cleanup)) > > ;; clean up... > > ))) > > > > There's a race here in case multiple threads try to change the cleanup > > procedure associated with that particular thread at the same time, but I > > suppose it is not an issue in practice. > > Fair enough, re: closures. But why should callers outside the current > thread be able to access that thread's cleanup handler procedure? > Maybe this isn't a realistic issue, but you could use this to "inject" > arbitrary code into a separate thread by setting the cleanup procedure > and immediately canceling the thread. Why not treat the handler as > thread-specific data? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel