Here is my functional, but not code complete, implementation of replacing web sockets over loopback network interface with unix sockets, to address #456 . I still want to do some more local stress testing before I say it is really ready, and I haven't even touched tests yet, but I wanted to post now to get some feedback on the approach. Also this is fully usable, with no changes needed to extensions, so anyone can try it out as well.

Since Ulauncher is already a Gtk based application, and thus has an included GLib event loop, I decided to leverage the capabilities included with GLib. This helps to push parts of the code down into the C library implementation of GLib, vs implementing the unix sockets with the python socket library. Unix sockets allow for better security since they can be created in user directories, with user permissions, thus leveraging the normal file system permissions for protection. Also, unix sockets have a bit less overhead even then local sockets, though this is unlikely to make a big impact in the Ulauncher case.

As part of making use of the event loop, I went on a bit of a thread slaying campaign, converting what I could from threads to events in the event loop. The hope was reduced potential race conditions and hopefully some reduced overhead. However, there are definitely a few run_async calls left that seem to be the easiest implementation, and unfortunately the Python threading library basically auto spawns a pool of threads on first use, so still a big pile of (presumably mostly idle) threads spawn off. Even so, I think many of the places I was able to convert into an event loop will generally help with the multi-thread nuances that can trip up code, so eliminating what I could still makes sense.

Looking at memory consumption of the main Ulauncher process, and of the extension processes, I see about a 40% memory reduction. I'd be curious if that varies with different environments. The savings don't look quite as nice if the preferences dialog is opened because doing so more than doubles the memory usage, which isn't reclaimed when it is closed. This makes the memory savings a much smaller percentage.

I'm interested in feedback on this approach. Also, I recognize some of the increased usage of the GLib event loop is not strictly related to the unix socket implementation, so for the ultimate "real" PR I can make it more focused if you think it is more appropriate. Then I can propose some of the other conversions in separate PRs.

A quick overview of the changes:

• ulauncher.utils.framer.PickleFramer: The WebSocket implementation provided the "framing" of the pickled objects, so I had to leverage a different mechanism to enclose each pickled event. I went with the standard XDR approach of a "bytes to follow" word, and then the data. This object also handles the pickling part and uses GLib signals for decoupling.
• ulauncher.api.shared.socket_path: Used the standard xdg runtime location for the unix socket path. On my system this is in "/run/user/"
• ulauncher.api.shared.event.RegisterEvent: The websocket implementation leveraged the path component of the initial connection to communicate the extension_id, so I had to create a new event to communicate this instead. The main process waits for this first register event before recording the extension as connected, since it doesn't know which extension connected until this point.
• Extension Server and Client: The overall flow is much the same, just with websockets swapped out with the Gio based unix socket service.
• ExtensionRunner: I swapped out the use of threads to launch and monitor processes with the Gio.Subprocess equivalent. This eliminates threads, but also hopefully further centralizes management of child processes, which necessarily tend to interact with SIGCHLD and trying to manage subprocesses from multiple threads can have pitfalls (since really only one thread "gets" the SIGCHILD).
• I'm not sure exactly which of the threads was causing the issues with Ctrl-C not working correctly without running Gtk.main() in a separate thread, but with the ones I eliminated I was also able to drop that work around. I think it might have been the websocket server thread, but I'd have to do more experiments to confirm. Either way, the work around can be dropped.

Sorry for the long message, but I thought it was good to provide the context and overview. As a final thought, I'm happy that this PR has a net removal of more than 400 lines, while increasing performance, reducing memory, and enhancing security. 😀