About Genode::Signal reception

[Norman Feske]

Hi Frank,

> I don’t think that a race condition contributes to the problem, because
> the first signal reception takes place after the call /tx.submit()/.
> Anyway, I made the suggested change (remove the thread start from the
> /Receiver/’s constructor and do it explicitly before the instantiation
> of /Signal_transmitter/), but again the signal was received twice.

yesterday prior answering your email, I was able to reproduce the
superfluous wakeup on Linux using the code snippets you provided. After
fixing the race condition, the superfluous wakeup does longer occur with
my test case. Today, I tested both variants  (race, no race) on OKL4_x86
and the superfluous wakeup never occurs here. For your convenience, I
have attached my test program to this email.

> I checked the properties of the signal, and indeed, as you supposed, on
> the first reception the parameter /num/ has the value *0*, while on the
> second reception the value is *1*. This would allow to ignore the
> unwanted signal as a temporary workaround, but the observed behaviour

Evaluating the 'num' value of the returned signal should not be a
temporary workaround - it is the only correct way to use the API if the
exact number of occurred signals are of importance to you.

> casts some doubt on the reliability of the signalling mechanism. There
> might by other situations where the signal is not at all received
> although it was sent once.

Please do not hesitate to substantiate this claim. I'm more than happy
about bug reports and test cases. Sharing your gut feeling with us does
not contribute to improve the framework though. .-)

Regards
Norman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: single_signal.tgz
Type: application/x-gzip
Size: 981 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20100706/c3f2ef3e/attachment.bin>