From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Threads in emacs implementation Date: Mon, 20 Jun 2005 13:48:09 +0200 Message-ID: <85acll6yh2.fsf@lola.goethe.zz> References: <6dbd4d0005060619227dd41364@mail.gmail.com> <87vf4oaft8.fsf@zemdatav.stor.no-ip.org> <4nd5quav0o.fsf@lifelogs.com> <4nll5btxv7.fsf@lifelogs.com> <4nvf4eqnec.fsf@lifelogs.com> <4nzmtpqdlp.fsf@lifelogs.com> <87fyvde30c.fsf@kanga.tapsellferrier.co.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1119268475 9409 80.91.229.2 (20 Jun 2005 11:54:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2005 11:54:35 +0000 (UTC) Cc: miles@gnu.org, Ted Zlatanov , snogglethorpe@gmail.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 13:54:26 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DkKqq-0003Vw-QH for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2005 13:54:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DkKx3-0002cj-W6 for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2005 08:00:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DkKvz-0002HZ-91 for emacs-devel@gnu.org; Mon, 20 Jun 2005 07:59:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DkKvx-0002GJ-00 for emacs-devel@gnu.org; Mon, 20 Jun 2005 07:59:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DkKvw-0002CT-1o for emacs-devel@gnu.org; Mon, 20 Jun 2005 07:59:20 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DkKnk-0004Pf-W0 for emacs-devel@gnu.org; Mon, 20 Jun 2005 07:50:53 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DkKkW-00076c-15; Mon, 20 Jun 2005 07:47:32 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id ABFB91C142D7; Mon, 20 Jun 2005 13:48:09 +0200 (CEST) Original-To: Nic Ferrier In-Reply-To: <87fyvde30c.fsf@kanga.tapsellferrier.co.uk> (Nic Ferrier's message of "Mon, 20 Jun 2005 11:28:19 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:39169 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39169 Nic Ferrier writes: > Miles Bader writes: > >> On 6/17/05, Ted Zlatanov wrote: >>> This will make threads more of a utility than a true built-in, and >>> threaded code would be written especially for that purpose. >> >> Do you know of any applications that require this? For many purposes, >> using timers etc. seems to work fairly well already. >> >> The main reason I can see for wanting threading is to allow users to >> continue using Emacs in one window while waiting for another window >> that's doing something (e.g. Gnus updating over a dialup). However >> that level of functionality is hard to implement. > > I think that's the problem isn't it? Analysis of what benefit Emacs > could get from threads. > > We don't need threads for improving GNUs - we just need better async > protocol implementations. They will come, slowly, but surely. The problem is that you always have a number of tasks that need to get tackled one after the other. And this can always done without threads or even subroutine calls, by storing all relevant details of the state, like counters, current point etc and so on and then jumping to central dispatch points. It is all the same for a computer. It isn't for a human. Subroutines and stacks are currently in use quite heftily for maintaining the inner state of some nested tasks pretty much in every programming language. Now if you have a data _stream_ passing between two different computing tasks, then each of those tasks has its own inner states to keep track of, its own local variables, its wn control structure and so on. Yes, you _can_ always explicitly hard-code all of that, but that means that you'll do so only when avoiding it would be more painful than the alternatives. When I was younger, I programmed a terminal emulator for use in a BIOS of mine, and several other stuff in that area. Now you have escape sequences for cursor positioning that go something like ESC [ row, column; or so (don't remember the details). So what states can the console output code be in? Well, it can be after the escape sequence, it can be in the middle of assembling of the row, it can be in the middle of assembling the column, stuff like that. And there are dozens of sequences like that. In the end, I programmed this more or less like basicloop: cp 1ah jp nz,noesc call getchar cp '[ jp nz,nocursor (actually, this was rather done via a jump table) call getnumber cp ', jnz badsequence push hl call getnumber pop de cp '; jnz badsequence set hl=something*hl + something*de ld (cursor),hl jp basicloop badsequence: sound bell jp basicloop getnumber: ld hl,0 push hl call getchar pop hl ret if a is not in '0..9 set hl=10*hl + a-'0 jmp getnumber Stuff like that. And then the tricky thing could all be done in "getchar". And getchar just switched from a local stack for the terminal emulator to the stack of the caller, and returned. And the console output simply switched from the stack of the caller to the stack of the terminal emulator, and returned. The whole "inner state" was maintained all inside of a separate stack. This was multithreading in connection with synchronous task switching, if you so wanted, even though in the 80s those buzzwords were not all around. And the purpose was to concentrate the "hard" stuff in very few locations, and facilitate "natural" programming everywhere else. And that's what multithreading is about: making conceptually easy tasks easy to code. Not merely making them possible to code: you can always hardcode the inner state maintained by the combination of a stack and the program counter. But it is hard, error-prone work. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum