The context ...
See the posix signals and the two delivery mechanisms: a kind of flag mechanism, then dealing with the original or standard signals, and a queue mechanism, when dealing with the extended, aka realtime signals.
So I know (or presume) that a call to pthread_kill while passing, as arguments, a standard signal and a valid thread, will always suceed.
In contrast, we have that a call to sigqueue while passing, as arguments, a valid and reachable process id, as well as valids signal and value, will fail and return the EAGAIN error, when the signal queue is full.
Ignore that while the former function points to a thread, the latter points to a process: the focus here is in the guarantee of delivery.
The doubt ...
What I wonder is: what can I expect when using pthread_kill to send realtime signals? Because once the interface does not specify EAGAIN as a possible error, then if blindly based on the interface specification (as I can see in the man pages), I can presume that the call will always suceed.
Is this right? Or there is some kind of catch I'm not seeing?
I could not find, in the docs or questions I saw until now, a clear answer to that.
EDIT: to clarify about the possible meanings pointed out by John Bollinger through his answer, follows.
I assumed "realtime" as a short term referring to "signal numbers between SIGRTMIN ... SIGRTMAX". Dont't known if this assumption is right. And (wrongly it seems) that this range determined the delivery mechanism .. queue of something else.
What I wonder is: what can I expect when using pthread_kill to send realtime signals?
It's unclear whether you can do that at all, depending in part on what you mean by "send realtime signals". In particular, although POSIX does attribute special delivery-order semantics to signal numbers between SIGRTMIN and SIGRTMAX, inclusive, it seems not to say that signals in that range are automatically queued. Nor that signals outside that range are never queued. On the contrary, it associates signal queuing with the manner in which signals are raised:
Some signal-generating functions, such as high-resolution timer expiration, asynchronous I/O completion, interprocess message arrival, and the
sigqueue()function, support the specification of an application-defined value [...] When a signal is generated by thesigqueue()function or any signal-generating function that supports the specification of an application-defined value, the signal shall be marked pending and, if the SA_SIGINFO flag is set for that signal, the signal shall be queued to the process along with the application-specified signal value. [...] It is unspecified whether signals so generated are queued when the SA_SIGINFO flag is not set for that signal.
So if by "send realtime signals" you mean "cause a signal to be queued for delivery" then I don't think pthread_kill() has that feature. At minimum, POSIX does not specify that it does. On the other hand, if you mean "send a signal in the range SIGRTMIN ... SIGRTMAX" then POSIX does not say that the signal will necessarily be queued, instead of delivered like any another signal, or even that pthread_kill() will send it at all (as far as the spec is concerned, it could fail with EINVAL instead).
Because once the interface does not specify EAGAIN as a possible error, then if blindly based on the interface specification (as I can see in the man pages), I can presume that the call will always suceed.
Is this right? Or there is some kind of catch I'm not seeing?
No, that does not seem to be right. POSIX does not require pthread_kill() to send signals in the range SIGRTMIN ... SIGRTMAX. It can fail with EINVAL instead. And if it does send them, then POSIX does not require it to queue them.