This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sigpending() incorrectly returns signals pending on other threads

On Mon, 15 Jul 2019 09:53:27, Corinna Vinschen  wrote:

> On Jul 14 15:19, Houder wrote:

> > .. uhm, just a note in the interest of accuracy ...
> >
> >  - standard signals (which include USRSIG1 and USRSIG2) are not queued
> >    (traditional signal semantics)
> >  - only real-time signals should be queued ...
> I think queing here means just what you outline above.  It's kind of a
> queue of pending signals and in Cygwin it's actually literally a queue.

> It's >>> a kind of _queue_ <<< of pending signals ...

Not a Q if it would mean that a specific signal can be inserted more than
once in this Q ...

I am fully aware that you know all about Unix/Linux, but

    for the sake of clarity:

20.12 (Signals are not queued) of LPI

    "The set of pending signals is only a "mask"; it indicates whether or
     not a signal has occurred, but NOT how many times it has occurred. In
     other words, if the same signal is generated multiple times while it
     is blocked, then it is recorded in the set of pending signals, and
     later delivered, just ONCE. (One of the differences between standard
     and realtime signals is that realtime signals are queued, as discussed
     in Section 22.8.)

     Listing 20-6 and Listing 20-7 show two programs that can be used to
     observe that signals are not queued. ... "

Meaning the queue in Cygwin is not really a Q ...


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]