[slime-devel] Re: Partial multiprocessing support on CMUCL

[Helmut Eller]

Luke Gorrie <luke at member.fsf.org> writes:

> Helmut Eller <e9626484 at 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.