Nic Ferrier <[EMAIL PROTECTED]> writes: > Miles Bader <[EMAIL PROTECTED]> writes: > >> On 6/17/05, Ted Zlatanov <[EMAIL PROTECTED]> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
