independent Lua threads in Hammerspoon for non-blocking long running lua code

165 views
Skip to first unread message

asmagill

unread,
Feb 23, 2016, 3:20:36 PM2/23/16
to Hammerspoon
https://github.com/asmagill/hammerspoon_asm/tree/master/luathread

It's limited to pure Lua/LuaRocks code and will error out (but not crash) if you attempt to load a Hammerspoon module that uses LuaSkin (i.e. almost all of them) within the thread, but it allows long-running lua code to execute in a non-blocking (to Hammerspoon) manner.

I am looking into some ways to possibly work around/replicate *some* of the Hammerspoon modules which could be safely/usefully run in a background thread, but want to do so without introducing changes into Hammerspoon or LuaSkin -- there are very good reasons why it requires main thread execution for most of what it does.

A shared dictionary can be created which allows passing lua data back and forth between the thread simply by getting or setting keyed entries in a table.



asmagill

unread,
Feb 29, 2016, 4:44:17 AM2/29/16
to Hammerspoon
The module has been moved to its own repository at https://github.com/asmagill/hs._asm.luathread and includes an experimental LuaSkin wrapper and currently has modified versions of some of Hammerspoon's modules:

hs.alert
hs.base64
hs.battery
hs.caffeinate
hs.crash
hs.drawing - (limited support in preparation for hs.pasteboard)
hs.drawing.color
hs.fs
hs.hash
hs.host
hs.json
hs.pathwatcher
hs.settings
hs.timer
hs.usb
hs.wifi

Chris Jones

unread,
Feb 29, 2016, 5:26:27 PM2/29/16
to asmagill, Hammerspoon
Hey

> On 29 Feb 2016, at 09:44, asmagill <asma...@icloud.com> wrote:
>
> The module has been moved to its own repository at https://github.com/asmagill/hs._asm.luathread and includes an experimental LuaSkin wrapper and currently has modified versions of some of

I'm very curious what you're using this for :)

Cheers,
Chris

asmagill

unread,
Feb 29, 2016, 5:46:17 PM2/29/16
to Hammerspoon, asma...@icloud.com
The initial impetus came from building menu structures for set of menus I have that offer various ways at getting to files I'm working on, applications, etc...  It uses quite few pathwatchers that build up some pretty complex menus based on file changes in various directories... if I update the menu structure every time a file changes, then everything in Hammerspoon slows down and if I just use the pathwatcher to set a flag indicating that the structure needs to be rebuilt the next time I click on the menu, then menu display becomes slow...

Thus the idea of keeping the structure consistent in a background thread so it's always current but doesn't block other things going on.

I probably have enough now that I could tackle that particular problem, but the module has kind of become interesting (to me at least) in its own right... just how much *can* be made "safe" in the background?  I'd never want this in core, since there are so many main-thread only/single-thread only/thread-safe/thread-unsafe questions that the OS X docs don't cover nearly as well as they probably should...

I posted it here in case anyone else wants to take a look or has an interest; this doesn't really belong in the Hammerspoon wiki.

Reply all
Reply to author
Forward
0 new messages