This is the mail archive of the mailing list for the glibc 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: Should pthread_kill be marked __THROW?

On Fri, 2016-04-08 at 11:30 -0700, Roland McGrath wrote:
> > I agree.  Calling a signal handler synchronously is not a concurrency
> > problem in the sense of synchronization with other threads.  The signal
> > handler can be considered concurrency, but then we should rather tell
> > the compiler that pthread_kill is like a raise, or not?
> I first read "a raise" as "a call to the 'raise' function", but now I think
> you actually meant "raising a C++ exception".  Is that right?

No.  I wasn't aware that ...

> Currently pthread_kill, kill{,pg}, sigqueue, and raise are all annotated
> in the same way (with our __THROW macro).  All of these have the same
> specified requirement that (in some circumstances) the signal handler run
> "inside" the function.  
> So raise is marked as never doing a raise.  That is the problem being cited.

... this is the problem, and thought that raise would be marked
correctly, and only pthread_kill would lack the marking.

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