Re: Single instance module and multithreading

From: Vais Salikhov <>
Date: Sat, 21 Feb 2009 19:41:27 -0500

Well, Benjamin, my scite irb is using luasocket as a client, so there
are no threading issues because it is not listening on a socket. I
will convert it over to textadept and make it available for anyone
interested as soon as I am done making myself completely at home with
textadept to start adding "luxuries" :)

Scite does have some form of multithreading baked in - you can see it
in the way running external commands is implemented - you can actually
stop a running command, which to me means it must be running in a
separate thread somehow.

I completely agree with your position on implementing these things as
separate modules - I believe this is entirely in the spirit of
textadept to keep a small native core that provides the basics and do
the rest in Lua. It is up to Mitchell though to decide if this is
going to make it into textadept, cause I would not even know where to
start :) I hope he does!



On Feb 21, 2009, at 7:16 PM, helgoboss <> wrote:

> Hi Vais,
> interesting use case, the ruby console thing. Didn't you have
> threading issues in SciTE as well? And if yes, how did you solve it?
> I wouldn't put the code for contacting Textadept from an outside
> process ("remote control" feature) into the core. It could be easily
> added by a module instead if there's multithreading support in the
> core (using LuaSocket). This would conform to Mitchell's principle of
> keeping the core as small and generic as possible. The "single
> instance" feature in turn could be an additional module which depends
> on the "remote control" module.
> We would have:
> * Module "LuaSocket" (essentially the "normal" LuaSocket packaged as
> Textadept module)
> * Module "Remote Control" (depends on "LuaSocket" module)
> * Module "Single Instance" (depends on "Remote Control" module)
> ... small modules that depend on each other, this makes them reusable.
> Greetings
> Benjamin
> On 21 Feb., 21:36, Vais Salikhov <> wrote:
>> 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.
>> Vais
>> 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
>>>>>'ssome 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 - 19:41:27 EST

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