From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Tue, 01 Feb 2011 11:57:20 -0800 Message-ID: <4D4865A0.8040903@gmail.com> References: <4D47DFD4.1040108@gmail.com> <87zkqg2bw3.fsf@uwakimon.sk.tsukuba.ac.jp> <87tygn3exw.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB854BB26C7EFB77B4F8A2C12" X-Trace: dough.gmane.org 1296590282 13316 80.91.229.12 (1 Feb 2011 19:58:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 19:58:02 +0000 (UTC) Cc: Tom Tromey , Lennart Borgman , rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 20:57:55 2011 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.69) (envelope-from ) id 1PkMME-0000Yd-Lo for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 20:57:53 +0100 Original-Received: from localhost ([127.0.0.1]:40144 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkMMB-0004XD-ND for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 14:57:43 -0500 Original-Received: from [140.186.70.92] (port=43902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkMM4-0004VP-OL for emacs-devel@gnu.org; Tue, 01 Feb 2011 14:57:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkMLy-0000AG-3a for emacs-devel@gnu.org; Tue, 01 Feb 2011 14:57:33 -0500 Original-Received: from mail-qy0-f176.google.com ([209.85.216.176]:44838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkMLv-00008i-Qp; Tue, 01 Feb 2011 14:57:27 -0500 Original-Received: by qyk10 with SMTP id 10so7281246qyk.0 for ; Tue, 01 Feb 2011 11:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type; bh=8sJcF5vyvla9mH30h5ild+/JkWlLohFDUgQfpY5N1Is=; b=FFY12E+12ILqPYyPoWWJ1eo56Ur0g2jqsg3kbD9sSVq6d1uBRUZG0oxGKV0hMt1G9L bCr7Mhrer2zLHYLZHEAbwEY5JPoY+ElPFYincto6VC6MYiZfmnjrpir1boUMmOoneqPO mrkAynEQyFtc+sLMpu0zopKxky7zQ+35vSHTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=YwnD5m5CF8+cgsBNjr3hG53v5W1o4p8GnZNnDPDFj6D3Hqd8sCKBHXba9Iuk0Y7vZQ JwyUp6KzxTKESh+9rNlfZRrIUX7EX3ypmA0ULwTCLq90u0xoFu1HQ5yEyHzK00EqDzw0 cMK8C26PffuBBkkaSb9yW+1jYoA7dtUwho8Ns= Original-Received: by 10.229.238.82 with SMTP id kr18mr7454785qcb.98.1296590247130; Tue, 01 Feb 2011 11:57:27 -0800 (PST) Original-Received: from edith.local (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id w12sm14795558qco.32.2011.02.01.11.57.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 11:57:26 -0800 (PST) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: <87tygn3exw.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.1.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.216.176 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:135425 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB854BB26C7EFB77B4F8A2C12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/1/11 8:19 AM, Stephen J. Turnbull wrote: > Lennart Borgman writes: > > On Tue, Feb 1, 2011 at 1:10 PM, Stephen J. Turnbull wrote: > > > Daniel Colascione writes: > > > > > > > The world is increasingly moving toward parallel processing, > > > > > > Since when does parallel processing =3D=3D threads? > >=20 > > I am a computer illiterate sometimes. Could you give us some hints > > about the current status? >=20 > Well, that's actually what I was asking Daniel. I'm not sure how > illiterate you think you are, so please try not to be insulted if it's > all too basic. That's an excellent overview of the topic. Thanks for writing it, Stephan= =2E You're absolutely correct in that multiprocessing can also take provide concurrency the ability to exploit SMP machines. But we've had it for decades, and it doesn't seem to be used very much to solve some persistent issues. Sure, flymake, flyspell, slime, M-x compile, find-grep, and friends allow a lot of work to happen asynchronously. But it's harder to use multiple processes to parallelize code written in elisp, especially code that interacts with the user. I actually prefer the shared-nothing multiprocessing approach in general, but it's hard to take advantage of that in Emacs today, at least for elisp. The startup time for a sub-Emacs (at least one that has also processed user startup code) is high, we have no fork exposed to elisp for easy data sharing, and there's no simple way to shuffle Lisp data structures between the Emacs processes, though at least with prin1 and read, the last easier than it'd be in some other systems. You could argue that bulk processing helpers should be written in something other than elisp --- and in practice, they are --- but it complicates both development and distribution. Have you seen the Python multiprocessing module? It provides a simple, elegant facilities to coordinate multiple communicating processes --- things like queues and pipes. A similar approach would work fine for Emacs as long as we're talking about bulk processing, e.g., parsing lots of RFC2822 messages, or indexing hairy C++. But for intricately coordinated work, it'd be a lot harder to allow these multiple processes to effectively manipulate the same buffer or communicate with the user: you'd have to either copy the whole thing, which could be expensive for large buffers and which would have child operate on stale data; you could provide a protocol for parent and child to talk about buffers over IPC, but that would introduces complexity, latency and coordination issues as well as a potentially large number of context switches; or you could put the buffer in shared memory and reintroduce some of the problems solved by multiprocessing as well as run into issues some platforms have with cross-process synchronization primitives. (ISTR a discussion of these options some time ago.) We could have two concurrency systems: a cooperative threads system for tasks inside an Emacs process that work closely with the user and that share the work of fontifying buffers, and another, high-level facility for offloading work to another Emacs process. This approach would solve some problems, but it'd be complex, and I suspect a lot of CPU-intensive code will nevertheless be run in the main Emacs process because it'd hard to logically separate buffer-dependent and buffer-independent work here. Or, instead of that complexity, we can use shared-everything threads --- which are inherently preemptive if they take advantage of hardware concurrency --- and deal with the fallout as best we can; other systems seem to manage. We could use locks and condition variables, or CSP, or (my favorite) STM. --------------enigB854BB26C7EFB77B4F8A2C12 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1IZaQACgkQ17c2LVA10Vu5lQCgu7NjxHvrVz+bmL4mR/QM6m5k LugAnidpHmF1sUgOiqulOhKGr7xZfOXW =g7ud -----END PGP SIGNATURE----- --------------enigB854BB26C7EFB77B4F8A2C12--