Re: Single instance module and multithreading

From: helgoboss <benjamin.k....at.gmail.com>
Date: Sat, 21 Feb 2009 16:16:00 -0800 (PST)

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 <vsalik....at.gmail.com> 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 <benjamin.k....at.gmail.com> 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 <vsalik....at.gmail.com> 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 <benjamin.k....at.gmail.com>  
> >> 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 ("check.if.already.open"
> >>> option). As you already have stated in a former thread (http://
> >>> groups.google.com/group/textadept/browse_thread/thread/
> >>> 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
> >>>http://lua-users.org/wiki/ThreadsTutorialthere'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
Received on Sat 21 Feb 2009 - 19:16:00 EST

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