Re: pgnus commandeers emacs to check mail
On Wed, Jul 21, 1999 at 01:29:33PM -0700, Rajesh Godbole wrote:
>>>>> Olivier Galibert writes:
> Oh yeah ? I'm really interesting in how using gtk/glib will
> make our _LISP_ code thread-safe.
Why do I get the feeling that I've opened a can of worms.
I tend to get a bit fed up with the "oh, add that because it's cool"
attitude. I've seen it repeated a lot on different projects I'm
working on lately, I just happen to be the one that pushed me over the
edge. Tough luck.
Okay, here's my $0.02. In order for threading to work with
emacs-lisp
the following things need to happen. (We're talking relatively long
term here, hence the word roadmap.)
o The OS
First off, the OS itself needs to "support" threads. Most industrial
strength OSes do so. Examples, DG/UX, HP/UX, AIX, Linux, Windoze,
^^^^^^^
Sun.
We call this system "Windows" on this mailing-list. We decided a long
time ago the 31337 h＠x0R attitude had nothing to do here. I don't
mean you have it, it's just that it's a bad habit to take.
AFAIK, all systems but MacOs XEmacs has been ported to have a decent
thread support.
o [x]emacs
[x]emacs would need to use a threaded library in order to support
multiple threads of execution within the same process. gtk/glib
would be _one_ solution. Its used extensively in gnome and mozilla.
gtk is not thread safe, not at all. Additionally, gtk documentation
is inexistant at best. You don't want to see the stunts I had to make
to show live video in a widget.
xemacs code would need to be made mt-safe by mutex-locking out
critical sections of the code.
Nice joke. Please define "critical sections of the code" in the case
of XEmacs in a way that doesn't involve 95% of the C code. I'm
waiting.
o emacs-lisp
the base emacs-lisp would need to provide extended lisp
functionality to interface with the low-level threads library.
This would probably be a package that provides mutex
Hint: XEmacs is written in lisp, not in C. The C part is only the
lisp engine, the basic functionalities needed to write an editor, and
the rewriting of some specific code too slow in lisp. Try again.
o emacs-lisp applications
Applications like gnus, w3 which can potentially do multiple
asynchronous fetches in the background would, probably benefit
from an mt emacs-lisp. Issues like how many threads (eg. 1
per newsgroup?) synchronization, mutual exclusion etc would
probably be counter-balanced by improvement in performance and
functionality.
If what you need is asynchronous I/O, add asynchronous I/O. It will
be even more performant because you will avoid all mutex funkiness.
A context switch between two threads in a single process is
considerably cheaper than a context switch between two processes.
Also, all data except for stack and registers are shared between
threads. This makes threading interesting for such apps.
kernel threads, or lisp threads ?
OG.