![]() |
|
||||
POSIX 1.c Migration Guide |
Signals
Controlling Blocked Signals
POSIX.4a defines the sigprocmask() function to examine and change blocked signals in both single-threaded and multi-threaded processes. In POSIX.1c, sigprocmask() must only be used in a single-threaded process; its behavior in a multi-threaded process is unspecified.
POSIX.1c defines the pthread_sigmask() function to examine and change blocked signals in either single-threaded or multi-threaded processes. Its behavior in a single-threaded process is the same as sigprocmask().
Synchronously Accepting Signals
The sigwait() function is the mechanism by which a thread may wait for one or more asynchronous signals. The differences between the various versions of this function and the POSIX.1c version are shown in the following table:
sigwait() Interface Changes POSIX.1c POSIX.4a pre-LynxOS 3.1.0LynxOS versions prior to 3.1.0 implemented a version of sigwait() based on the POSIX.4 Draft 9 event interface, which permits the return of an arbitrary value associated with the event causing the signal. POSIX.1c-compliant applications should instead use the sigwaitinfo() function for this purpose.
Thread-Based Event Notification
POSIX.1c defines a new mechanism for signal-based event notification: execution of a specified notification function as an independent thread. This mechanism is enabled by specifying the SIGEV_THREAD value for the sigev_notify member of the sigevent structure. Two new sigevent structure members specify the required thread information:
New sigevent Structure Members Member Name Member TypeThe sigev_notify_function is executed in an environment as if it were the start_routine to pthread_create() with thread attributes specified by sigev_notify_attributes. As with pthread_create(), the value NULL can be used to specify default attributes. If the attributes are explicitly specified, the detachstate attribute must be set to PTHREAD_CREATE_DETACHED, otherwise the behavior is undefined.
The following code fragment demonstrates the usage of this capability to run a high-priority thread associated with the expiration of a high-resolution
interval timer:int event_data;
/* Retrieve the event data from the argument */
event_data = value.sival_int;
:
/* Some high-priority processing here ... */
:
pthread_exit((void *)0);
int rv;
int prio;
pthread_attr_t attr;
struct sched_param param;
struct sigevent event;
timer_t timer;
struct itimerspec timerspec;
:
/* Create and initialize the event thread */
/* attributes so that it will be run at a */
/* high, fixed priority */
rv = pthread_attr_init(&attr);
:
rv = pthread_setinheritsched(&attr,
PTHREAD_EXPLICIT_SCHED);
:
rv = pthread_setschedpolicy(&attr, SCHED_OTHER);
:
prio = sched_get_priority_max(SCHED_OTHER);
param.sched_priority = prio - 10;
rv = pthread_attr_setschedparam(&attr, ¶m);
:
rv = pthread_attr_setdetachstate(&attr,
PTHREAD_CREATE_DETACHED);
:
/* Initialize the event struct */
(void)memset(&event, 0, sizeof(event));
event.sigev_notify = SIGEV_THREAD;
event.sigev_notify_function = timer_thread;
event.sigev_value.sival_int = 0xdeadbeef;
event.sigev_notify_attributes = &attr;
:
/* Set up a 1 second periodic interval timer */
rv = timer_create(CLOCK_REALTIME, &event, &timer);
:
timerspec.it_interval.tv_sec = 1;
timerspec.it_interval.tv_nsec = 0;
timerspec.it_value.tv_sec = 1;
timerspec.it_value.tv_nsec = 0;
rv = timer_settime(timer, 0, &timerspec,
NULL);
:
/* Each time the interval timer expires,*/
/* the timer_thread will be run */
:
}
Signal Delivery Semantics
LynxOS versions prior to 3.1.0 could exhibit non-standard signal delivery behavior in a multi-threaded application where a signal was pending, but there were no threads blocked in sigwait() for that signal. In this case, the root thread would have the signal made pending against it, even if the it had the signal blocked but one or more of the other threads did not.
LynxOS 4 corrects the behavior for this case, ensuring that a pending signal is delivered to the first thread eligible to run that has the signal unblocked. Applications ported to LynxOS must not depend on the old behavior.
![]() LynuxWorks, Inc. 855 Branham Lane East San Jose, CA 95138 http://www.lynuxworks.com 1.800.255.5969 |
![]() |
![]() |
![]() |
![]() |