Does not use dbus, this is a choice keeps the option of portability by not using the abstract namespace.

Might be a good idea to be more clear about why not using D-Bus is a caveat. (It's hard to get "per desktop session" operation for uniqueness and IPC unless you use D-Bus.)

D-Bus gets session-scoped by having its socket path stored in an environment variable in the session startup scripts, but not much else I can think of that's usable for IPC has that kind of setup on your average X11 desktop.

The only other "per-session" option that readily comes to mind as working out of the box would be to generate a randomly named domain socket then store the name to it in a property on the X11 root window so other things in the same session can find it.

@ssokolow I haven't used dbus because it keeps the options open for porting to other *nix systems where there is no dbus. Of course, in such cases, the user needs to

1. avoid using the Linux abstract namespace

2. set up mechanisms for automatically cleaning up the socket once the work is done. Also it has to be ensured that the residual socket does not persist a program/system crash. Saving the socket in RAMDISK might be a good option.

Since it lacks the advantages of dbus, this method might not be usable for all use cases as suggested in the article.

True... but that assumes there's a standard way to find a RAM disk. Last I heard, /dev/shm and /run being RAM disks was a Linux-specific convention.

I prefer to start by incorporating some means by which the new process can check whether the socket is stale and flush the old socket automatically.

If it's user-scoped rather than session-scoped, also using a single, un-changing name which incorporates the user's homedir or UID is also a good way to ensure that stale handles can't pile up. (eg. ~/.mozilla/firefox/PROFILE_NAME/lock)

BTW, the strange Expected macro is more idiomatically done with a type alias type Expected<T> = Result<T, Box<dyn Error>>.