This is definitely _safe_ but slower.
NOTE: set_current_state() is _always_ safe. __set_current_state() may be
race prone if not used carefully in the wait_event interface.
In the sepecific above case you can safely use the faster
__set_current_state() because you know the schedule will run on the same
CPU that you used to set the state as TASK_INTERRUPTIBLE. You are changing
the `state' field only for yourself. So you don't care what other CPUs
will see as you have not to deal with other CPUs in such case.
The signal handling can't race as schedule is aware of signals and
schedule will check if there's a signal pending after flushing the
TASK_INTERRUPTIBLE state to the other CPUs and the signal path will first
set the signal_pending bit, then it flush the bit to RAM and it will go to
check the state of the signalled process. So the right ordering is
just enforced by the scheduler and the signal code.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/