From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giuseppe Scrivano Newsgroups: gmane.emacs.devel Subject: Re: multi-threaded Emacs Date: Sat, 29 Nov 2008 22:01:26 +0100 Message-ID: <873ahant5l.fsf@master.homenet> References: <87abbiody1.fsf@master.homenet> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1227992534 31290 80.91.229.12 (29 Nov 2008 21:02:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Nov 2008 21:02:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 29 22:03:16 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L6Wxv-00077g-Ju for ged-emacs-devel@m.gmane.org; Sat, 29 Nov 2008 22:03:00 +0100 Original-Received: from localhost ([127.0.0.1]:43112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6Wwl-0006Xn-J2 for ged-emacs-devel@m.gmane.org; Sat, 29 Nov 2008 16:01:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6Wwa-0006SG-Ok for emacs-devel@gnu.org; Sat, 29 Nov 2008 16:01:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6WwZ-0006Rk-Pb for emacs-devel@gnu.org; Sat, 29 Nov 2008 16:01:36 -0500 Original-Received: from [199.232.76.173] (port=42392 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6WwZ-0006Rc-Kk for emacs-devel@gnu.org; Sat, 29 Nov 2008 16:01:35 -0500 Original-Received: from jack.mail.tiscali.it ([213.205.33.53]:45999) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6WwZ-0000gv-1W for emacs-devel@gnu.org; Sat, 29 Nov 2008 16:01:35 -0500 Original-Received: from master.homenet (84.222.168.192) by jack.mail.tiscali.it (8.0.022) id 48F74810021802B8; Sat, 29 Nov 2008 22:01:32 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1L6WwQ-000721-MP; Sat, 29 Nov 2008 22:01:26 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 29 Nov 2008 15:26:21 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106321 Archived-At: Hello, Stefan Monnier writes: > - handling thread-specific data: gcprolist, mark_byte_stack, and things > like that. You've tackled this one. I don't find your solution very > elegant, but I can't think of a much better one, unless pthreads does > provide some kind of thread-specific variables. I guess the only > improvement is to put those vars together, so we have an array of > structs (that then contain gcprolist, and mark_byte_stack fields) > rather than several arrays. And then define `gcprolist' as a macro > that expands into "thread_data[current_thread()].gcprolist", so as to > reduce the amount of source-code changes. Yes, we can put thread-specific data together in a struct; what about buffer data? `current_buffer' must be different for every thread so as many other global variables, should it be defined in the same thread_data struct? > - dynamic-scoping: your handling of specpdl is naive and > fundamentally flawed. For multithreading, we will have to completely > change the implementation technique of dynamic-scoping. I know but it was the easier way to have quickly a working proof-of-concept as I concentrated my efforts mainly on the syntax. Do you have any idea about how dynamic scoping should be handled in a multi-threaded environment? > - synchronization to access all the global variables/objects. > You haven't yet have time to tackle this (other than in `put', it > seems), and it's going to be difficult. Why do you think that a global lock (or several ones for separate kind of data) will not be enough? It is not easy but I think it can be done in a reasonable time without many troubles. > - concurrent GC (later to be refined to parallel concurrent GC ;-). > > - redisplay in its own thread (later to be refined to one redisplay > thread per terminal, then per frame, then per window ;-). I think that this is the most difficult part, a new GC and how handle redisplay. Different threads can use the same buffer and a buffer can have no threads actually using it. I would simplify this part, maybe leave the redisplay task only to a thread. > A first step will be to restrict the implementation such that there's no > parallelism: only one thread executes at any given time (i.e. have > a single lock and have all thread grab the lock before doing any actual > work). IMHO it is better to avoid this middle solution and try to solve directly the problem, it will not give real benefits and having only one thread executes at a given time can be done differently, like saving and restoring the thread call stack. Real threads will not suffer I/O bound operations and Emacs will be able to use more cores at the same time, if needed. Thanks, Giuseppe