From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: [0/10] threads for emacs Date: Thu, 09 Aug 2012 13:59:48 -0600 Message-ID: <87obmjdeff.fsf@fleche.redhat.com> References: <87zk63eu2p.fsf@fleche.redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344542395 21520 80.91.229.3 (9 Aug 2012 19:59:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 19:59:55 +0000 (UTC) To: Emacs discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 09 21:59:56 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SzYtf-00053w-QD for ged-emacs-devel@m.gmane.org; Thu, 09 Aug 2012 21:59:55 +0200 Original-Received: from localhost ([::1]:36230 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzYtf-0003Ub-4b for ged-emacs-devel@m.gmane.org; Thu, 09 Aug 2012 15:59:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzYtc-0003UR-Jn for emacs-devel@gnu.org; Thu, 09 Aug 2012 15:59:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzYtb-0003KE-D4 for emacs-devel@gnu.org; Thu, 09 Aug 2012 15:59:52 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:2040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzYtb-0003Ju-2n for emacs-devel@gnu.org; Thu, 09 Aug 2012 15:59:51 -0400 Original-Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q79JxoKt016422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Aug 2012 15:59:50 -0400 Original-Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q79Jxml2021623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 Aug 2012 15:59:49 -0400 X-Attribution: Tom In-Reply-To: <87zk63eu2p.fsf@fleche.redhat.com> (Tom Tromey's message of "Thu, 09 Aug 2012 13:36:30 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152385 Archived-At: Tom> Plus I have a to-do list... I thought it would be worthwhile to post it. First, I think the patches I've posted are all (except maybe #9 and #10) necessary for a first cut at threads in Emacs. There are a few other things I think are necessary before the feature can be easily useful: * Documentation * Emacs Lisp condition variable code. This is probably not too hard. * Changes to the process code so that a process can be restricted to having its output accepted by a single thread. (In fact I think the default should be to do this for the creating thread.) This avoids introducing bugs into lisp code that may currently make assumptions about let bindings visible to process filters. * Hook into the Emacs I/O code so that the global lock is released when a thread enters 'select' (and maybe other primitives). I think this is a bit harder than it sounds, mostly because I think you don't want multiple threads to select on the same fds. It probably requires the process changes. * Figure out what, if anything, to do about the lisp debugger, redisplay, and the keyboard when running a "non-background" thread. * More tests Some nice-to-have things: * Have mutex-lock automatically detect deadlocks. * Add a mutex function to see what thread owns a lock. Less sure about this one, but it seems handy for debugging. * See if we can make it so there is a thread per keyboard. * (provide 'thread) at the right spot * Some convenience macros, like 'with-mutex' * Change gnus so 'g' runs in the background. Isn't that what this is really all about? The far-flung future, aka stuff I don't anticipate getting to: * Redo the bindings code to be more efficient * Change thread switching to happen more often, say every N calls to QUIT. * Eventually, remove the interpreter lock. I think the current design still allows this (though some details in the current code would have to be changed). This is very tricky though. Tom