[RTEMS Project] #2228: POSIX timers misbehaviour

[RTEMS trac]

#2228: POSIX timers misbehaviour
-------------------------+-------------------
 Reporter:  systec-dk    |       Owner:
     Type:  defect       |      Status:  new
 Priority:  normal       |   Milestone:  4.11
Component:  cpukit       |     Version:  4.10
 Severity:  normal       |  Resolution:
 Keywords:  posix timer  |
-------------------------+-------------------

Comment (by systec-dk):

 Replying to [comment:2 chrisj]:
 > First a brief inspection of the kill code to check if it is ok to call
 from an isr shows _POSIX_signals_Vectors being check before disabling
 dispatching. Is this ok ? The sigaction code has protected references.

 I cannot comment on this, because I don't understand the RTEMS internals
 regarding this matter.

 > Second the kill call hits all threads in the system including classic
 threads and here I am concerned classic API tasks could assume no POSIX
 support enabled and therefore no signals and so no handling for an
 unexpected signal. Further this code will not have any support for pthread
 sigmasks and so it will not be able to manage signals in the same way
 pthread code should. Should kill be hitting all threads ? This makes sense
 from the kill call point of view so should there exist a means to deliver
 a signal to only the POSIX threads ?

 According to cpukit/posix/src/pthread.c:_POSIX_Threads_Create_extension()
 classic threads are configured so that all POSIX signals are blocked.
 Hence killinfo() won't deliver any POSIX signal to a classic thread.
 Furthermore killinfo() has support for pthread sigmask. It is stored in
 api->signals_blocked.

 > Oh and why does a getpid check happen at the start of kill ? Are we
 expecting another pid to ever exist ?

 I was surprised too about this check. I think currently it will never
 fail.

--
Ticket URL: <http://devel.rtems.org/ticket/2228#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project