Re: Single instance module and multithreading

From: Vais Salikhov <>
Date: Sat, 21 Feb 2009 15:36:52 -0500

I agree, Benjamin, being able to run a socket server inside textadept
would open up a number of possibilities outside of managing textadept
instances. I used luasocket with scite to communicate with a running
instance of ruby interpreter, essentially turning any scite buffer
into an irb console with live autocompletion. It would be interesting
to see what can be done if textadept itself could be contacted from an
outside process. I am curious to see what Mitchell has to say about
the feasibility of this idea.


On Feb 21, 2009, at 1:55 PM, helgoboss <> wrote:

> Hello Vais,
> as you say, an external launcher application would need to communicate
> with the Textadept process as well, which is currently not possible. I
> don't know whether there's a way to do interprocess communication
> which does not require a separate listener thread, and even if there
> is any it's probably not cross-platform. I liked the idea that sockets
> are a simple and platform-neutral way to solve the problem and that
> the core does not need to be modified only for the sake of one use
> case. Multithreading support would probably make sense for future
> modules, too.
> Regards
> Benjamin
> PS: I'm on Windows.
> On 21 Feb., 18:09, Vais Salikhov <> wrote:
>> Could this perhaps be solved with an external application (let's call
>> it "ta") that accepts requests to open files and forwards them to a
>> single textadept instance that it "manages"? Just a thought. This
>> would still require some way to communicate with a textadept process,
>> but would externalize multi-threading to another application. What
>> other ways can be used to do interprocess communication that do not
>> involve luasocket? I assume you are on Linux, because this is already
>> how textadept works on OS X.
>> Vais
>> On Feb 21, 2009, at 11:43 AM, helgoboss <>
>> wrote:
>>> Hello Mitchell, hello community,
>>> I often use an external file manager or the command line to locate
>>> text files and open them in Textadept (by invoking the Textadept
>>> executable with the path of the text file as argument), I almost
>>> never
>>> use the "Open file" command of Textadept. Unfortunately, after a
>>> while
>>> I've so many open Textadept instances that I loose track because
>>> there's one Textadept window for each open text file. I'd prefer to
>>> have only one Textadept window for all open text files to avoid
>>> chaos
>>> on my Desktop.
>>> The solution would be a "single instance" feature which ensures that
>>> there's never more than one instance of Textadept running. All
>>> further
>>> invocations of the Textadept executable would be "redirected" to an
>>> existing Textadept process. As a side effect, that would also
>>> shorten
>>> the time to open the text file and save system resources. Such a
>>> feature can be found for example in SciTE (""
>>> option). As you already have stated in a former thread (http://
>>> f71dd38eb7202781/525f8093b292508f?
>>> lnk=gst&q=instance#525f8093b292508f), this feature probably won't
>>> make
>>> its way into the core, understandibly. Nevertheless, I think the
>>> feature is indispensible for some people.
>>> In Textadept, everything is about extensibility, so I tried to add
>>> this feature as a Textadept module. This module uses LuaSocket to do
>>> the inter-process communication stuff in a platform-independent
>>> manner. Sockets are a popular approach to enable "single instance"
>>> support for applications. However, I ran into a serious issue,
>>> explained below, which makes it impossible to get the single
>>> instance
>>> module to work.
>>> It's planned to work like this: On startup, Textadept checks whether
>>> port x is free. If yes, it can be assumed that this is the first
>>> Textadept instance, so it starts listening for remote messages on
>>> this
>>> port. If not, it can be assumed that this is a second instance, so
>>> it
>>> connects to port x and sends a message containing the command line
>>> arguments to the first Textadept instance. After this, the second
>>> instance quits immediately. The first Textadept instance in turn
>>> interprets the message and loads a file into a new buffer.
>>> The showstopper is that Lua has no native support for
>>> multithreading.
>>> Listening on a socket means blocking the whole thread of execution -
>>> which would make Textadept unusable if there's only one thread.
>>> That's
>>> why it's absolutely necessary to do the listening stuff in a
>>> separate
>>> thread. There are some Lua modules out there that enable
>>> multithreading and don't need a modified lua.dll, for example
>>> LuaLanes, but they render unusable because they don't give the
>>> possibility to share global data among threads. However, the socket
>>> listener thread **needs** to access global data, in particular it
>>> needs to access the same "textadept" Lua table like the main
>>> thread in
>>> order to have control over Textadept.
>>> I think, the only possibility would be to add multithreading support
>>> in the Textadept core (could be helpful for other modules as
>>> well). On
>>>'s some information
>>> about how to do this. It could work roughly like this: The Textadept
>>> module code written in Lua invokes a function
>>> "textadept.start_in_new_thread(lua_code)" (implemented by the C
>>> core)
>>> which executes the specified Lua code in a new thread. In
>>> particular,
>>> the C core starts a new thread (pthread or winapi) and initializes a
>>> new Lua state in this thread. It binds all the global data like the
>>> textadept table to the new Lua state and then lets Lua interpret the
>>> specified code.
>>> Unfortunately, threads which share global data also introduce the
>>> problem of race conditions. I've no idea how much effort it would
>>> take
>>> to make the Textadept core thread safe.
>>> I would be happy to see some comments on this, thanks. Question to
>>> Mitchell: Do you plan to add multithreading support in future?
>>> Cheers
>>> Benjamin
> >
Received on Sat 21 Feb 2009 - 15:36:52 EST

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