Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #1987 > unrolled thread

Clarification for the handling of sigwaitinfo()

Back to article view | Back to comp.programming.threads

Contents

  Clarification for the handling of sigwaitinfo() Markus Elfring <Markus.Elfring@web.de> - 2013-11-16 16:16 +0100
    Re: Clarification for the handling of sigwaitinfo() Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2013-11-16 20:23 +0000
      Re: Clarification for the handling of sigwaitinfo() Markus Elfring <Markus.Elfring@web.de> - 2013-11-17 10:50 +0100
        Re: Clarification for the handling of sigwaitinfo() Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2013-11-17 11:11 +0000
          Re: Clarification for the handling of sigwaitinfo() Markus Elfring <Markus.Elfring@web.de> - 2013-11-17 13:30 +0100

#1987 — Clarification for the handling of sigwaitinfo()

[Multipart message — attachments visible in raw view] — view raw

Hello,

I try to wait for various signals in a dedicated thread on my openSUSE system as
you can see it from the attached source file.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwaitinfo.html

I wonder why this small test program does not work as expected so far. I get the
error message "my_receiver: Signal wait failed." after a signal was sent to the
corresponding process.

I would appreciate your advices.

Regards,
Markus

[toc] | [next] | [standalone]

#1988

On Sat, 16 Nov 2013 16:16:42 +0100
Markus Elfring <Markus.Elfring@web.de> wrote:
> Hello,
> 
> I try to wait for various signals in a dedicated thread on my
> openSUSE system as you can see it from the attached source file.
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwaitinfo.html
> 
> I wonder why this small test program does not work as expected so
> far. I get the error message "my_receiver: Signal wait failed." after
> a signal was sent to the corresponding process.
> 
> I would appreciate your advices.

I may have missed it (the code is quite dense) but I could not see
on a quick read where you blocked asynchronous delivery of the signal to
the process, so that sigwait() could pick it up.

Chris

[toc] | [prev] | [next] | [standalone]

#1989

> I may have missed it (the code is quite dense) but I could not see
> on a quick read where you blocked asynchronous delivery of the signal to
> the process, so that sigwait() could pick it up.

I thought that my function call "pthread_sigmask(SIG_SETMASK, &signal_set,
NULL)" does this. Did I interpret the return value of the function "sigwaitinfo"
in the wrong way here?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#1990

On Sun, 17 Nov 2013 10:50:16 +0100
Markus Elfring <Markus.Elfring@web.de> wrote:

> > I may have missed it (the code is quite dense) but I could not see
> > on a quick read where you blocked asynchronous delivery of the
> > signal to the process, so that sigwait() could pick it up.
> 
> I thought that my function call "pthread_sigmask(SIG_SETMASK,
> &signal_set, NULL)" does this. Did I interpret the return value of
> the function "sigwaitinfo" in the wrong way here?

So you did, and you preceded it with sigfillset(), so that is fine.

Yes I think it is the return value of sigwaitinfo() which you are
interpreting incorrectly.  According to POSIX:

"Upon successful completion (that is, one of the signals specified by
set is pending or is generated) sigwaitinfo() ... shall return the
selected signal number. Otherwise, the function shall return a value of
-1 and set errno to indicate the error."

I presume here "return the selected signal number" means really return,
not (in the case of success) providing it via the 'info' out parameter
(which it is also required to do if not NULL).  Since no signal number
has value 0, neither success nor failure will return 0.

This is quite confusing, as sigwait() does return 0 in case of success
and provide the signal number via its out parameter.

Chris

[toc] | [prev] | [next] | [standalone]

#1991

[Multipart message — attachments visible in raw view] — view raw

> Yes I think it is the return value of sigwaitinfo() which you are
> interpreting incorrectly.

Thanks for your feedback.

My source file seems to work as expected after a small adjustment.

Regards,
Markus

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web