Re: Could each Emacs frame utilize a thread?

[Kevin A. Burton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eli Zaretskii <address@hidden> writes:

> On 9 Dec 2001, Kevin A. Burton wrote:
> 
> > Couldn't each new frame utilize a new thread/process?
> 
> Richard and others might have a broader perspective, but I believe starting a
> new thread for each frame would require a massive rewrite of many crucial
> parts of Emacs.

That is what I was thinking as well.

I wanted to get some input from Emacs developers who are more familar with Emacs
internals than I.

I wonder if a solution could be worked out where we agreed that this was the
case (that a thread for each frame would be difficult) and worked out some
alternatives.

Maybe the ability to share 'objects' between Emacs processes?

Specifically I am thinking of the ability to startup one main Emacs process,
this would create an object (defuns, bytecode, buffers, etc) pool in memory.

Then another Emacs could share content from the first session.

This would give us most of the benefits of a multithreaded app and also the
benefit redundancy (one emacs process could fail without all of them failing).  

... anyway ... just an idea.

I realize that the emacs server can do this... but you still get the startup
time hit, especially if you have a LOT of lisp loaded, like I do.

> The current code base assumes single-threaded operation in too many places,
> and there are lots of global variables lying around which prohibit reentrancy.

yes... and doing this in C is a pain.

> > When I fetch gnus in one frame it shouldn't prohibit me from editing in
> > another frame.
> 
> I believe Gnus has an option you can flip to make it do some of its work
> asynchronously.  This works by running some of the code off an idle timer,
> like stealth font-lock does.

Hm.  I will check into that.
<snip>

- -- 
Kevin A. Burton ( address@hidden, address@hidden, address@hidden )
             Location - San Francisco, CA, Cell - 415.595.9965
        Jabber - address@hidden,  Web - http://relativity.yi.org/

,@b=map{xB8,unxb8,chr($_^$a[--$h+84])address@hidden;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))address@hidden"C*",@a}';s/x/pack+/g;eval

 -- Perl version of DeCSS.  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE8FI83AwM6xb2dfE0RAphsAJ4nz+HlPrscX0zu8OwfEN0AC1CkAwCgyTO1
HnAR91tLiH/q6I6uM7L3pbw=
=L9j0
-----END PGP SIGNATURE-----