Alan Ruttenberg alanralanr@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