[slime-devel] Re: eval-string bug?

[Luke Gorrie]

Alan Ruttenberg <alanralanr at comcast.net> writes:

> BTW, I've run into a limitation of the current multiprocessing
> scheme. E.g. if you have a single repl that is busy then you can't
> meta-point or macroexpand. Was the creation of a dedicated control
> stream considered and rejected?

It was pushed onto the To-Think list :-)

I'm in agreement. Possibly we should go even further and have Emacs
only interact directly with one thread, and have it farm out the work
as needed (possibly without Emacs knowing/caring how) and do
multiplexing through a single socket.

Do you want to take a turn at redoing it?

Reluctantly I have to take a break from the fun to do some boring
stuff (vacation), so I'll be away from the end of next week until
mid-March. Meanwhile I have time to discuss but not code another
threads design :-)

One thought is this: currently our state machine expects orderliness
from Lisp - we send one request at a time, except an answer, etc. To
accomodate multithreading we added one similarly orderly connection
for each thread.

Maybe a better idea would have been to go for chaos? We send N
requests to Lisp at a time, and it replies in any order (with an ID
tag to identify the result), we can get multiple unknown threads
hitting the debugger at the same time, etc.

I don't have details worked out, but it if this could be made to work
it would seem quite flexible. The existing scheme doesn't seem to fit
well with options like thread-per-request -- too many sockets and
generally Emacs having to know too much about what threads Lisp has.

(With a design nod to Peter Siebel and Brian Downing.)

Cheers,
Luke