Re: Threads in emacs implementation

[David Kastrup]

Nic Ferrier <address@hidden> writes:

> Miles Bader <address@hidden> writes:
>
>> On 6/17/05, Ted Zlatanov <address@hidden> 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