Luke Gorrie luke@member.fsf.org writes:
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
What do you think about Gary Byers comment that multi-threading support could be seen as a special case of multi-session support?
Would it be easier if each thread had its own connection to Emacs? Each connection with its own state machine and buffers etc.
I hadn't taken it in before -- I reread it and it does sound appealing. With each Lisp thread having a separate socket, they shouldn't have to do any synchronization amongst themselves for our benefit.
The first question that occurs is how to do the flow control. I wonder if it could be done neatly by putting the "foreground" Emacs network-process into asynchronous/process-filter mode, and switch the others to synchronous I/O and not read from them?
Hmm, not sure if I understand the problem. I think, if every thread has it's own connection with a separate state machine and associated buffers, we can do almost everything like we do now. We just have to make sure the we do it in the right buffer, something like per-session variables. And of course, we need a way to allow the thread to initiate the new connection.
Also, by allowing more things to happen asynchronously, it seems like we're getting more race-conditions and it could complicate the state machine quite a lot. I'm starting to wonder if we could move some of the state out of Emacs and into Lisp alone, so that it doesn't have to be synchronized. I haven't got any good examples yet.
Yes, if we have only one state machine on the Emacs side, it's probably better to move the protocol checking to the Lisp side.
BTW, I notice you replied privately -- better not to air too much dirty laundry on the list, do you think?
This was not intended, I must have pressed the wrong key.
Helmut.