blocks|key|309663|text|根据POSIX标准，所有线程在系统上都应该使用相同的PID，并且可以使用pthread_sigmask()为每个线程定义信号阻塞掩码。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|309664|由于每个PID只允许定义一个信号处理程序，因此我更喜欢在一个线程中处理所有信号，如果需要取消正在运行的线程，则发送pthread_cancel()。它是反对pthread_kill()的首选方式，因为它允许为线程定义清理函数。|309665|在一些较旧的系统上，由于缺乏适当的内核支持，正在运行的线程的PID可能与父线程的PID不同。有关使用linuxThreads+on+Linux+2.4处理信号的信息，请参阅常见问题解答。|309666|entityMap|0|LINK|mutability|MUTABLE|url|http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#J^0|10|H|0|1L|G|26|E|0|1E|P|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@$9|10|A|11|1|12]]|E|$]]|$1|J|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

According to the POSIX standard all threads should appear with the same PID on the system and using <code>pthread_sigmask()</code> you can define the signal blocking mask for every thread. 

Since it is allowed to define only one signal handler per PID, I prefer to handle all signals in one thread and send <code>pthread_cancel()</code> if a running thread need to be cancelled. It is the preferred way against <code>pthread_kill()</code> since it allows to define cleanup functions for the threads.

On some older systems, because of the lack of proper kernel support, the running threads may have different PID from the parent thread's PID. See FAQ for signal handling with <a href="http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#J" rel="nofollow noreferrer">linuxThreads on Linux 2.4</a>.

blocks|key|314708|text|到目前为止，我所处的位置：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|314709|314710|信号有不同的主要类别，其中一些通常只会终止进程(SIGILL)，而另一些永远不需要做任何事情(SIGIO；不管怎样，只做异步IO更容易)。这两个类不需要动作。|unordered-list-item|314711|有些信号不需要立即处理；像SIGWINCH这样的类可以排队等待，直到它方便了(就像来自X11的事件一样)。|314712|那些棘手的信号是你想要通过中断正在做的事情来响应它们，但又不会影响到清除线程的程度。特别是，在交互模式下登录应该让事物具有响应性。|314713|314714|我仍然需要对POSIX、pselect、sigwait、sigaltstack以及其他一大堆POSIX(和非POSIX)进行比较。|offset|length|style|CODE|314715|entityMap^0|0|0|0|0|0|0|C|7|K|7|S|B|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]|$M|11|N|12|O|P]|$M|13|N|14|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|R|$]]

Where I'm at so far:

<ul>
<li>Signals come in different major classes, some of which should typically just kill the process anyway (SIGILL) and some of which never need anything doing (SIGIO; easier to just do async IO right anyway). Those two classes need no action.</li>
<li>Some signals don't need to be dealt with immediately; the likes of SIGWINCH can be queued up until it is convenient (just like an event from X11).</li>
<li>The tricky ones are the ones where you want to respond to them by interrupting what you're doing but without going to the extent of wiping out a thread. In particular, SIGINT in interactive mode ought to leave things responsive.</li>
</ul>

I've still got to sort through <code>signal</code> vs <code>sigaction</code>, <code>pselect</code>, <code>sigwait</code>, <code>sigaltstack</code>, and a whole bunch of other bits and pieces of POSIX (and non-POSIX) API.

blocks|key|309679|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|309680|blockquote|309681|309682|309683|控制将信号传递到哪个线程的最佳方法是什么？|unordered-list-item|309684|309685|正如@zoli2k所指出的，显式地指定一个线程来处理您希望处理的所有信号(或一组线程，每个线程都具有特定的信号职责)是一种很好的技术。|309686|309687|309688|309689|告诉另一个线程(实际上可能很忙)的最好方法是什么，告诉它信号已经发生了，我可以安全地处理将一个信号已经发生的信息传递给其他线程吗，arrived?...|309690|How，，|309691|，|309692|？这需要在信号处理程序中发生吗？|309693|309694|309695|我不会说“最好的”，但这是我的建议：|309696|阻塞main中所有所需信号，以便所有线程都继承信号掩码。然后，将特殊的信号接收线程设计成一个信号驱动的事件循环，将新到达的信号作为发送给其他线程内的通信。|offset|length|style|CODE|BOLD|309697|要做到这一点，最简单的方法是让线程使用sigwaitinfo+or+sigtimedwait在循环中接受信号。然后线程以某种方式转换信号，可能是广播一个pthread_cond_t，用更多的I/O唤醒其他线程，将命令排入特定于应用程序的线程安全队列中，等等。|309698|或者，特殊线程可以允许将信号传递给信号处理程序，仅在准备好处理信号时才取消对传递的屏蔽。(然而，通过处理程序的信号传递往往比通过sigwait系列的信号接收更容易出错。)在这种情况下，接收器的信号处理程序执行一些简单的异步信号安全操作:设置sig_atomic_t标志，调用sigaddset(&signals_i_have_seen_recently,+latest_sig)，将一个字节的write()传递给非阻塞self-pipe，等等。然后，回到其屏蔽的主循环中，线程如上所述将信号的接收传递给其他线程。|309699|(更新了+@caf，正确地指出sigwait方法更优越。)|309700|entityMap|0|LINK|mutability|MUTABLE|url|http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigtimedwait.html|1|http://cr.yp.to/docs/selfpipe.html^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|2|4|1T|B|0|J|B|Y|C|24|E|J|R|0|0|1S|7|3C|C|3T|1G|5G|5|5T|9|1|0|1|3|F|7|0^^$0|@$1|2|3|-4|4|5|6|1M|7|@]|8|@]|9|$]]|$1|A|3|-4|4|B|6|1N|7|@]|8|@]|9|$]]|$1|C|3|-4|4|5|6|1O|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1P|7|@]|8|@]|9|$]]|$1|E|3|F|4|G|6|1Q|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1R|7|@]|8|@]|9|$]]|$1|I|3|J|4|5|6|1S|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|L|3|-4|4|B|6|1U|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|1V|7|@]|8|@]|9|$]]|$1|N|3|O|4|5|6|1W|7|@]|8|@]|9|$]]|$1|P|3|Q|4|G|6|1X|7|@]|8|@]|9|$]]|$1|R|3|S|4|G|6|1Y|7|@]|8|@]|9|$]]|$1|T|3|U|4|G|6|1Z|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|20|7|@]|8|@]|9|$]]|$1|W|3|-4|4|5|6|21|7|@]|8|@]|9|$]]|$1|X|3|Y|4|5|6|22|7|@]|8|@]|9|$]]|$1|Z|3|10|4|5|6|23|7|@$11|24|12|25|13|14]|$11|26|12|27|13|15]]|8|@]|9|$]]|$1|16|3|17|4|5|6|28|7|@$11|29|12|2A|13|14]|$11|2B|12|2C|13|14]|$11|2D|12|2E|13|14]]|8|@$11|2F|12|2G|1|2H]]|9|$]]|$1|18|3|19|4|5|6|2I|7|@$11|2J|12|2K|13|14]|$11|2L|12|2M|13|14]|$11|2N|12|2O|13|14]|$11|2P|12|2Q|13|14]]|8|@$11|2R|12|2S|1|2T]]|9|$]]|$1|1A|3|1B|4|5|6|2U|7|@$11|2V|12|2W|13|15]|$11|2X|12|2Y|13|14]]|8|@]|9|$]]|$1|1C|3|-4|4|5|6|2Z|7|@]|8|@]|9|$]]]|1D|$1E|$4|1F|1G|1H|9|$1I|1J]]|1K|$4|1F|1G|1H|9|$1I|1L]]]]

<blockquote>
 <ul>
 <li>What's the best way to control which thread
 a signal is delivered to?</li>
 </ul>
</blockquote>

As @zoli2k indicated, explicitly nominating a single thread to handle all signals you want handled (or a set of threads each with specific signal responsibilities), is a good technique.

<blockquote>
 <ul>
 <li>What is the best way to tell another thread (that might actually be busy)
 that the signal has arrived?[...]</li>
 <li>How can I safely handle passing the information that a signal has occurred
 to other threads? Does this need to happen in the signal handler?</li>
 </ul>
</blockquote>

I won't say "best," but here's my recommendation:

Block all desired signals in <code>main</code>, so that all threads are inherit that signal mask. Then, fashion the special signal receiving thread as a signal-driven event loop, dispatching newly arrived signals as some other intra-thread communication.

The simplest way to do this is to have the thread accept signals in a loop using <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigtimedwait.html" rel="noreferrer"><code>sigwaitinfo</code> or <code>sigtimedwait</code></a>. The thread then converts the signals somehow, perhaps broadcasting a <code>pthread_cond_t</code>, waking up other threads with more I/O, enqueuing a command in an application-specific thread-safe queue, whatever.

Alternatively, the special thread could allow signals to be delivered to a signal handler, unmasking for delivery only when ready to handle signals. (Signal delivery via handlers tends to be more error-prone than signal acceptance via the <code>sigwait</code> family, however.) In this case, the receiver's signal handler performs some simple and async-signal-safe action: setting <code>sig_atomic_t</code> flags, calling <code>sigaddset(&amp;signals_i_have_seen_recently, latest_sig)</code>, <code>write</code>() a byte to a non-blocking <a href="http://cr.yp.to/docs/selfpipe.html" rel="noreferrer">self-pipe</a>, etc. Then, back in its masked main loop, the thread communicates receipt of the signal to other threads as above.

(UPDATED @caf rightly points out that <code>sigwait</code> approaches are superior.)

blocks|key|3266160|text|IMHO、Unix+V信号和posix线程不能很好地混合。Unix+V是1970年。POSIX为1980+;)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3266161|有一些取消点，如果你在一个应用程序中允许信号和pthread，你最终会在每个调用周围编写循环，这可能会令人惊讶地返回EINTR。|3266162|因此，在我不得不在Linux或QNX上编程多线程的(少数)情况下，我所做的是屏蔽所有(除了一个)线程的所有信号。|3266163|当Unix+V信号到达时，进程会切换堆栈(在Unix+V中，这是您在一个进程中可以获得的最多并发)。|3266164|正如这里的其他帖子所暗示的那样，现在可以告诉系统，哪个POSIX线程应该是堆栈切换的牺牲品。|3266165|一旦你成功地让你的信号处理器线程工作了，问题仍然存在，如何将信号信息转换成其他线程可以使用的文明的东西。需要用于线程间通信的基础设施。一种有用的模式是参与者模式，其中每个线程都是某个进程内消息传递机制的目标。|3266166|因此，您应该尝试将信号从信号上下文编组到您的信号处理程序线程，然后使用您的角色模式通信机制向那些需要信号相关信息的角色发送语义上有用的消息，而不是取消其他线程或杀死它们(或其他奇怪的东西)。|3266167|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

IMHO, Unix V signals and posix threads do not mix well.
Unix V is 1970. POSIX is 1980 ;)

There are cancellation Points and if you allow signals and pthreads in one application, you will eventually end up writing Loops around each call, which can surprisingly return EINTR.

So what I did in the (few) cases where I had to program multithreaded on Linux or QNX was, to mask out all signals for all (but one) threads.

When a Unix V Signal arrives, the process Switches the stack (that was as much concurrency in Unix V as you could get within a process).

As the other posts here hint, it might be possible now, to tell the System, which posix thread shall be the victim of that stack switching.

Once, you managed to get your Signal handler thread working, the question remains, how to transform the signal information to something civilized, other threads can use. An infrastructure for inter-thread communications is required. One pattern, useful is the actor pattern, where each of your threads is a target for some in-process Messaging mechanism.

So, instead of canceling other threads or killing them (or other weird stuff), you should try to marshall the Signal from the Signal context to your Signal handler thread, then use your actor pattern communications mechanisms to send semantically useful messages to those actors, who need the signal related Information.

I've been trying to understand the intricacies of how POSIX threads and POSIX signals interact. In particular, I'm interested in:

<ul>
<li>What's the best way to control which thread a signal is delivered to (assuming it isn't fatal in the first place)?</li>
<li>What is the best way to tell another thread (that might actually be busy) that the signal has arrived? (I already know that it's a bad idea to be using pthread condition variables from a signal handler.)</li>
<li>How can I safely handle passing the information that a signal has occurred to other threads? Does this need to happen in the signal handler? (I do not in general want to kill the other threads; I need a far subtler approach.)</li>
</ul>

For reference about why I want this, I'm researching how to convert the <a href="http://sourceforge.net/projects/tclx/" rel="noreferrer">TclX</a> package to support threads, or to split it up and at least make some useful parts support threads. Signals are one of those parts that is of particular interest.

POSIX threads and signals

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我一直在尝试理解POSIX线程和POSIX信号交互的错综复杂之处。我特别感兴趣的是：控制信号传递到哪个线程的最好方法是什么(假设它首先不是致命的)？告诉另一个线程(实际上可能很忙)信号已经到达的最佳方法是什么？(我已经知道从信号处理程序中使用pthread条件变量不是一个好主意。)如何安全地处理将信号已发生的信息传递给...

问POSIX线程和信号
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问POSIX线程和信号EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问POSIX线程和信号
EN