Bugs POSIX API Timer

[Nico Forlano]

Hi,

>> I attached two examples that demonstrate both cases. If you compile 
>> them on Linux, they behave as I would expect from the POSIX
documentation.
> Can you attach these to a PR so we can track this?

I will sometime this week.

> Did you find an explicit statement for a call to kill() or just that 
> this is documented as part "per-process timers"?

No, just that the POSIX documentation refers to them as "per-process
timers".
kill() was just my own interpretation on how to send a signal to the entire
process.

> Off the top of my head, we should be able to mask the signals at the 
> process level and only enable them individually for the threads.
> Still a change.

Yes that can be done. However the issue is that in the current test there
are several threads and each thread is assigned one individual timer. Each
thread block /waits for his timer's signal, but all timers emit the same
signal (SIGALRM). If the timer signal is emitted at process level and all
threads block / wait for SIGALRM, there is no way to tell which thread react
to which timer's signal. I suspect for the example to function as it does
now, each thread - timer pair has to be assigned a unique signal (e.g.
SIGUSR1, SIGUSR2).

Regards
Nico

On Mon, August 12, 2013 00:59, Joel Sherrill wrote:
> Sorry for the delay. I was on travel and not in a good position for 
> deep thought.
> 
> On 8/5/2013 2:38 PM, Nico Forlano wrote:
>> Hi,
>>
>> I think I found two bugs / unexpected behaviour in the POSIX timer 
>> implementation
>>
>> 1.) Emitted signal on timer expiration is only relayed to the thread 
>> which created the timer instead of the process / all threads.
> I think you are correct and we are wrong. When implementing this, I 
> personally leaned to making some items more thread specific. In some 
> cases, you had to and in this one, I may have gone too far.
>> 2.) When you initialize a timer with an interval of zero, the timer 
>> is supposed to expire only once and then stop. You would expect that 
>> the value remains at zero in this case, however in RTEMS the timer 
>> resets to an arbitrary (?) value and starts counting down again.
> Looking at posix/src/timertsr.c, the method 
> _POSIX_Timer_Insert_helper() is only invoked if it is non-zero.
> 
> I am suspicious the error is in timergettime.c which is not looking
>>
>> I attached two examples that demonstrate both cases. If you compile 
>> them on Linux, they behave as I would expect from the POSIX
documentation.
> Can you attach these to a PR so we can track this?
> 
> I certainly need to run them.
>> Regarding 1.):
>> Sebastian Huber pointed out to me that  _POSIX_Timer_TSR() emits the 
>> signal with an explicit call to pthread_kill(). From the POSIX 
>> documentation I would have expected a signal to all threads of the 
>> process using kill().
> Did you find an explicit statement for a call to kill() or just that 
> this is all documented as part "per-process timers"?
> 
> I just want to make sure I am reading the same sections you are.
>> If this is changed I believe the psxtimer01 test from the POSIX part 
>> of the testsuit has to be updated as well. There are three threads 
>> which all create their own timer and all wait for a signal with the 
>> same signal number. If the threads are not addressed directly with 
>> pthread_kill() anymore I assume the highest priority thread will just 
>> grab the signals of all timers, which does not seem to be the 
>> intention.
> Off the top of my head, we should be able to mask the signals at the 
> process level and only enable them individually for the threads.
> Still a change.
>> If the usage of pthread_kill() is intended, is there any way to set 
>> the ID of the target thread?
> Not within POSIX but that's an interesting idea.
> 
> If you aren't bound to POSIX, the Classic API Timers are much more 
> flexible.
>> Regards
>> Nico
>>
>>
> 
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
> 
>