>>>
>>> I'm afraid we need nklock around enqueue and dequeue so that we neither
>>> lose a signal nor warn needlessly.
>>
>> I thought there might be multiple signals pile up here but actually this
>> warn never
>> happen according to my test with smokey sigdebug test item after applying
>> the patch.
>>
>>>
>>>> + (sigwork->self == sigwork))) {
>>>
>>> What case is this part of the test excluding?
>>
>> Because we have not initted them after xnthread is allocated, some data
>> might not be empty I guess at the first time of using
>> according to my test . That was why I said I found duplicate signal case in
>> previous thread when I did not add it but actually it was not
>> multiple signals case causing return.
>> If signal can be queued , it is quite different than what we had discussed.
>> Actually I do not know in which case multiple signals
>> would pile up here after splitting into slots. At least , I cannot reproduce
>> multiple singles pile up issue with sigdebug test item.
>> If we consider queue to avoid losing signals for multiple signal in same
>> slot , how can we decide the size of queue for each slot?
>> Sorry for late response, I was taking AL.
>>
>
>No problem. Please have a look what is meanwhile in master, review it,
>stress it, and if you see issues that we missed, please speak up. It's
>not queuing, it's first-come-first-serve.
I miss initializing sigarray when we use xnthread->task to check if there is
signal pending because there is random data when it have not
been initialized that cause failure of sigdebug test. Please review new patch
https://xenomai.org/pipermail/xenomai/2021-June/045642.html
>
>Jan
>
>--
>Siemens AG, T RDA IOT
>Corporate Competence Center Embedded Linux
>
>
