Re: Single instance module and multithreading

From: vais <vsalik....at.gmail.com>
Date: Sun, 22 Feb 2009 06:51:23 -0800 (PST)

I agree with Vyacheslav on the lanes approach to threading in TA. If
it is to be done at all, that should probably be the way. However,
please let's remember to keep TA simple.

> I think that threading support of some sort is absolute must for TA, because
> it seems impossible to implement REPL or debugger without it.

Not sure about implementing a debugger, but REPL is definitely doable
without threads - I have done it. I do not think threading support is
"absolute must for TA" - it is a "nice to have", and only if it can be
done without adding unnecessary complexity. Remember, there are plenty
of editors and IDEs out there - TA has a mission of its own, and
simplicity and extensibility by users is big part of it. HAVING TO
deal with threading can be a big turn off. If threading can be
unobtrusive so that one can effectively ignore it unless needed, I
would be all for it :)

Vais

On Feb 22, 7:29 am, helgoboss <benjamin.k....at.gmail.com> wrote:
> Hi Vyacheslav,
>
> > I think TA should adopt approach which is common for GUI libraries: only a
> > single thread should have access to the real "controls" (to textadept table,
> > in your terms) and all others should send requests to this thread.
>
> I thought about this, too. Like in Java the Swing AWT event thread. Do
> you have any idea how this is usually implemented? Thinking loud:
> There must be something like an event queue that contains pieces of
> code to be executed in sequence by the main thread. And the secondary
> threads do nothing else than appending pieces of code to this queue.
>
> Nevertheless, the event queue still has to be accessed in some way
> from the secondary threads. How would you accomplish this with the
> approach taken by LuaLanes? Anyway, the event queue approach would
> release the burden of making everything thread safe, that sounds good.
>
> > In fact before choosing a threading abstraction we should first collect
> > different use cases. Then we should assess threading abstractions according
> > to their applicability to those different use cases.
>
> Concerning the use cases, until now we have:
> * Listening on a socket in background (for remote controlling and
> single instance feature)
> * Running an external process and printing output continuously into a
> Textadept buffer
>
> Regards
Received on Sun 22 Feb 2009 - 09:51:23 EST

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:37:30 EST