fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-10-26 05:13:34 +08:00
Code Issues Packages Projects Releases Wiki Activity

Cosmetic cleanup from SIGCHLD changes

Browse Source 
git-svn-id: http://svn.code.sf.net/p/nuttx/code/trunk@5514 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo
2013-01-13 00:35:47 +00:00
parent b58281cab8
commit ffda55b34a
3 changed files with 11 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
apps/examples/ostest/sighand.c
+6 -1
View File
@@ -57,7 +57,12 @@ static bool threadexited = false;
#ifdef CONFIG_SCHED_HAVE_PARENT #ifdef CONFIG_SCHED_HAVE_PARENT
static void death_of_child(int signo, siginfo_t *info, void *ucontext) static void death_of_child(int signo, siginfo_t *info, void *ucontext)
{ {
/* Use of printf in a signal handler is NOT safe! It can cause deadlocks! */ /* Use of printf in a signal handler is NOT safe! It can cause deadlocks!
* Also, signals are not queued by NuttX. As a consequence, some
* notifications will get lost (or the info data can be overwrittedn)!
* Because POSIX does not require signals to be queued, I do not think
* that this is a bug (the overwriting is a bug, however).
*/
if (info) if (info)
{ {
nuttx/ChangeLog
+1 -1
View File
@@ -3918,7 +3918,7 @@
the scenario: (1) sched_lock() is called increments the lockcount the scenario: (1) sched_lock() is called increments the lockcount
on the current TCB (i.e., the one at the head of the ready to run on the current TCB (i.e., the one at the head of the ready to run
list), (2) sched_mergepending is called which may change the task list), (2) sched_mergepending is called which may change the task
at the head of the readytorun list, then (2) sched_lock() is called at the head of the readytorun list, then (2) sched_unlock() is called
which decrements the lockcount on the wrong TCB. The failure case which decrements the lockcount on the wrong TCB. The failure case
that I saw was that pre-emption got disabled in the IDLE thread, that I saw was that pre-emption got disabled in the IDLE thread,
locking up the whole system. locking up the whole system.
nuttx/sched/task_deletecurrent.c
+4 -2
View File
@@ -115,9 +115,12 @@ int task_deletecurrent(void)
* does not correspond to the thread that is running. Disabling pre- * does not correspond to the thread that is running. Disabling pre-
* emption on this TCB and marking the new ready-to-run task as not * emption on this TCB and marking the new ready-to-run task as not
* running (see, for example, get_errno_ptr()). * running (see, for example, get_errno_ptr()).
*
* We disable pre-emption here by directly incrementing the lockcount
* (vs. calling sched_lock()).
*/ */
sched_lock(); rtcb->lockcount++;
rtcb->task_state = TSTATE_TASK_READYTORUN; rtcb->task_state = TSTATE_TASK_READYTORUN;
/* Move the TCB to the specified blocked task list and delete it */ /* Move the TCB to the specified blocked task list and delete it */
@@ -143,7 +146,6 @@ int task_deletecurrent(void)
* the lockcount on rctb. * the lockcount on rctb.
*/ */
DEBUGASSERT(rtcb->lockcount > 0);
rtcb->lockcount--; rtcb->lockcount--;
return OK; return OK;
} }