Re: Are there plans for a multi-threaded Emacs?

[Vinicius Jose Latorre]

Kai Grossjohann <address@hidden> writes:

>  Miles Bader <address@hidden> writes:
>  
>  > Consider a simple bit of elisp code:  (setq GLOBAL (cons 'x GLOBAL))
>  > In a pre-emptively threaded emacs, another thread could run between
>  > accessing GLOBAL and setting it.  Whoops.
>  
>  Well, I don't know a lot about threading, but Java, at least, has the
>  same problem: you need to synchronize access to a variable to prevent
>  such things from happening.  By default, synchronized access is turned
>  off.
>  
>  So if all of what is now in Emacs continues to run in a single thread,
>  and you just provide a function to create a new thread and run stuff
>  in that new thread, then it would be the responsibility of the people
>  creating threads to make sure that they don't step on each other's
>  toes.
>  
>  Then the remaining problem is that possibly a lot of functions cannot
>  be safely used because they access global variables.  But that is just
>  something that people will have to live with, and maybe it will get
>  better over time.  I think that it will be good enough at least for
>  some packages to do part of their work in the background.
>  
>  What do people think?  Maybe I missed something obvious...

I also don't know a lot about threads, but CHILL (old) language also has a
mechanism of mutual exclusion.  So, one could define a thread, other defines
another thread, if both of them need to share some resource (variables) they
define a region of mutual exclusion where the resources (variables) can be
accessed only by procedure calling.

Maybe I also missed something obvious...

Vinicius