进程结束/死亡时共享 POSIX 对象清理

发布于 2024-08-10 20:53:15 字数 315 浏览 4 评论 0原文

有没有办法执行 POSIX 共享同步对象清理,特别是在进程崩溃时?锁定的 POSIX 信号量解锁是最理想的事情,但自动“收集”队列/共享内存区域也很好。另一件需要注意的事情是我们通常不能使用信号处理程序,因为 SIGKILL 无法被捕获。

我只看到一种选择:一些接受订阅和“保持活动”请求的外部守护程序作为看门狗工作,因此没有有关某些对象的通知,它可以根据注册的策略关闭/解锁对象。

有没有更好的替代方案/建议?我以前从未认真使用过 POSIX 共享对象(套接字足以满足我的所有需求,并且在我看来更有用),并且我没有找到任何适用的文章。我很乐意在这里使用套接字,但由于历史原因而不能。

Is there any way to perform POSIX shared synchronization objects cleanup especially on process crash? Locked POSIX semaphores unblock is most desired thing but automatically 'collected' queues / shared memory region would be nice too. Another thing to keep eye on is we can't in general use signal handlers because of SIGKILL which cannot be caught.

I see only one alternative: some external daemon which accepts subscriptions and 'keep-alive' requests working as watchdog so not having notifications about some object it could close / unlock object in accordance to registered policy.

Has anyone better alternative / proposition? I never worked seriously with POSIX shared objects before (sockets were enough for all my needs and are much more useful by my opinion) and I did not found any applicable article. I'd gladly use sockets here but can't because of historical reasons.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

無處可尋 2024-08-17 20:53:15

您可以使用文件锁定来协调进程,而不是使用信号量。文件锁的一大优点是,如果进程终止,它们就会被释放。您可以将每个信号量映射到共享文件中一个字节的锁上,并知道锁将在退出时释放;在大多数版本的 unix 中,您锁定的字节甚至不必存在。 Marc Rochkind 的《高级 Unix 编程》第一版中有相关代码,但不知道是否在最新的第二版中。

Rather than using semaphores you could use file locking to co-oridinate your processes. The big advanatge of file locks being that they are released if the process terminates. You can map each semaphore onto a lock for a byte in a shared file and know that locks will get released on exit; in mosts version of unix the bytes you lock don't even have to exist. There is code for this in Marc Rochkind's book Advanced Unix Programming 1st edition, don't know if it's in the latest 2nd edition though.

尛丟丟 2024-08-17 20:53:15

我知道这个问题已经很老了,但另一个很好的解决方案是 POSIX 强大的互斥体。当所有者死亡时,它们会自动解锁并进入“不一致标志”状态,下一个尝试锁定互斥锁的线程会收到 EOWNERDEAD 错误,但会成功成为互斥锁的新所有者。然后,它能够清除互斥锁所保护的任何状态(由于前一个所有者的异步终止,这可能处于非常糟糕的不一致状态!),并在解锁之前将互斥锁再次标记为一致。

请参阅此处有关强大互斥体的文档:

http://pubs.opengroup.org/onlinepubs /9699919799/functions/pthread_mutex_lock.html

I know this question is old, but another great solution is POSIX robust mutexes. They automatically unlock and enter an "inconsistent flag" state when the owner dies, and the next thread to attempt locking the mutex gets an EOWNERDEAD error but succeeds in becoming the new owner of the mutex. It's then able to clean up whatever state the mutex was protecting (which could be in a very bad inconsistent state due to asynchronous termination of the previous owner!) and mark the mutex as consistent again before unlocking it.

See the documentation on robust mutexes here:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

海的爱人是光 2024-08-17 20:53:15

通常的方法是使用信号处理程序。只需捕获信号并调用清理函数即可。

但是你的看门狗守护进程也有一些优点。这肯定会使系统更易于理解和管理。为了使管理更简单,您的应用程序应该在守护进程未运行时启动它,并且守护进程应该能够清除上次崩溃的任何残留物。

The usual way is to work with signal handlers. Just catch the signals and call the cleanup functions.

But your watchdog daemon has some merits, too. It would surely make the system more simple to understand and manage. To make it more simple to administrate, your application should start the daemon when it's not running and the daemon should be able to clean up any residue from the last crash.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文