From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Wed, 02 Feb 2011 01:19:39 +0900 Message-ID: <87tygn3exw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4D47DFD4.1040108@gmail.com> <87zkqg2bw3.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1296577724 3940 80.91.229.12 (1 Feb 2011 16:28:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 16:28:44 +0000 (UTC) Cc: Tom Tromey , Daniel Colascione , rms@gnu.org, emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 17:28:39 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 1PkJ5j-0000Ae-Bl for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 17:28:38 +0100 Original-Received: from localhost ([127.0.0.1]:36236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkJ5a-0004jA-Hq for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 11:28:22 -0500 Original-Received: from [140.186.70.92] (port=59192 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkJ5T-0004P0-12 for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:28:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkJ5P-0000eI-Gn for emacs-devel@gnu.org; Tue, 01 Feb 2011 11:28:12 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:44457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkJ5O-0000db-Vh; Tue, 01 Feb 2011 11:28:11 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id C386A970671; Wed, 2 Feb 2011 01:28:06 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 64BC01A3007; Wed, 2 Feb 2011 01:19:39 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:135404 Archived-At: Lennart Borgman writes: > On Tue, Feb 1, 2011 at 1:10 PM, Stephen J. Turnbull = wrote: > > Daniel Colascione writes: > > > > =A0> 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? 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. By *definition*, both threads and processes are ways of multitasking which allow various forms of "parallel processing", such as multi-CPU processing and time-slicing. There are other forms of parallel processing, such as GPUs on the video card and DMA for I/O, but these are rather specialized. In *theory*, both threads and processes should be capable of being distributed across processors, and AFAIK they both work pretty well in practice each with its advantages and disadvantages. The specific difference between threads and processes is that threads share all resources of a single process *except* the instruction counter, and thus can communicate with each other with maximum efficiency. Processes do not share resources with each other, and thus it is impossible (absent an OS or hardware bug) for one process to stomp on another's resources, thus providing maximum safety for each task. In fact there are intermediate possibilities, for example shared memory allows two separate processes to access the same memory. Any variables stored in that area are efficiently communicated between the processes. Now, in practice threads require protection from each other, just as processes do when accessing disk (thus the infamous "stale lock" problem in CVS and Subversion, which many workflows for dVCSes can reduce to almost zero). If you allocate a resource on the heap (often called "consing" in Lisp, and is commonly extended to resources other than Lisp conses), then in theory only a thread hold a pointer to it can access it, thus providing some protection. However, a wild pointer "for (p =3D memory; ; p++) { write(stuff,p); }" can trash another thread's private resources, while this can't happen with processes. The problem with threads as I see it, and I believe this is why Richard and Guido express pessimism too, is that Lisp objects tend to get all linked together. Tasks that follow the links and mutate the objects are likely to interfere with each other, but that is a very common pattern in dynamic languages. In Python, this is handled with the GIL, or global interpreter lock.[1] In many circumstances, a thread must grab that lock, excluding all other threads from running. This also is somewhat expensive in terms of CPU AIUI. Many proposals have been made to remove the GIL from Python, but (so far) they all fall down because it turns out that keeping track of lots of "local" locks is either very expensive, or deadlock-prone. (The "STM" that I mentioned in connection with Haskell and Simon Peyton-Jones is more or less a technique for automatically managing "local" locks, and has been applied successfully in some projects.) Of course, processes also involve high costs, specifically the cost of context switching when interrupting one process and starting another, and the cost of copying shared data back and forth between the cooperating processes. But on balance my intuition (FWIW, probably not much in this case :-) is that threads are fundamentally a low-level, performance-oriented implementation of the high-level abstraction "concurrent task", and that there's a severe impedence mismatch with Lisp, especially Emacs Lisp. Footnotes:=20 [1] I refer here to the mainline Python written in C. Jython and IronPython are based on different virtual machines which don't have GILs.