因为没找到，所以计划自己手搓一个简单的凑合用。
计划这样做：一个高权限运行的daemon，负责调度任务；一个用普通用户运行的客户端，负责向daemon提交任务、取消任务等，操作完就关闭。
现在的问题是：两个进程之间如何通信？计划用unix socket（windows最近一两年也已经支持了），因为服务器上需要识别出提交任务时的用户，调度到他的任务时需要切换过去执行。
现在的两个问题是：
1. 除了 unix socket，有没有更合适的ipc方案？性能不需要很高，容易开发、运行稳定最重要。需要可以识别出提交任务时的用户。
2. 用 unix socket 的话，C++有什么适合的高级一些的库？

RE: xn--s8w913fdga.chn....

@chn 可以用DBus，还有 @coelacanthus 之前提到的varlink，这些都可以传比较结构化的数据

@aleksana@bcom.moe @coelacanthus@mastodon.yuuta.moe 我今天才知道windows也有移植的dbus。
不过看起来这两种方法都不是特别成熟（指用的人不多）。因为这个是在生产环境中使用的，所以最后决定用boost asio + unix socket，序列化用现成的json库。

@chn @aleksana KDE 那些应用程序倒是在 Windows 上都用 DBus

@coelacanthus@mastodon.yuuta.moe @aleksana@bcom.moe 问一下，dbus有没有什么方法获得对方的用户id？因为要做多用户的支持。
我发现windows上的unix socket似乎没有办法获得客户端的uid。那这个路子就走不通了。

@chn @aleksana Call dbus_message_get_sender() to get the caller's D-Bus id, and then call GetConnectionUnixProcessID to get the pid of the process that sent the message.

@coelacanthus @chn @aleksana 好奇是什么条件要求在 Windows 上做这个……

@ncts@dabr.ca @coelacanthus@mastodon.yuuta.moe @aleksana@bcom.moe 一些计算软件只有windows版本，一个windows服务器要很多人一起使用，所以需要一个工具来排队。

@chn @aleksana @ncts 如果是这种场景感觉没必要直接在机制里获取 UID 啊，完全可以在计算请求的包的划个字段声明用户