diff options
author | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2013-01-13 00:35:47 +0000 |
---|---|---|
committer | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2013-01-13 00:35:47 +0000 |
commit | 0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3 (patch) | |
tree | f74938699bd760dbbba52578827f5e100d7b3700 | |
parent | 499c8c86de6757b39eaaf0f2b96a5b070f085b9b (diff) | |
download | px4-nuttx-0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3.tar.gz px4-nuttx-0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3.tar.bz2 px4-nuttx-0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3.zip |
Cosmetic cleanup from SIGCHLD changes
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5514 42af7a65-404d-4744-a932-0658087f49c3
-rw-r--r-- | apps/examples/ostest/sighand.c | 7 | ||||
-rw-r--r-- | nuttx/ChangeLog | 2 | ||||
-rw-r--r-- | nuttx/sched/task_deletecurrent.c | 6 |
3 files changed, 11 insertions, 4 deletions
diff --git a/apps/examples/ostest/sighand.c b/apps/examples/ostest/sighand.c index 63d9590d9..32b182c21 100644 --- a/apps/examples/ostest/sighand.c +++ b/apps/examples/ostest/sighand.c @@ -57,7 +57,12 @@ static bool threadexited = false; #ifdef CONFIG_SCHED_HAVE_PARENT 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) { diff --git a/nuttx/ChangeLog b/nuttx/ChangeLog index 921b7014b..7deb9fa94 100644 --- a/nuttx/ChangeLog +++ b/nuttx/ChangeLog @@ -3918,7 +3918,7 @@ 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 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 that I saw was that pre-emption got disabled in the IDLE thread, locking up the whole system. diff --git a/nuttx/sched/task_deletecurrent.c b/nuttx/sched/task_deletecurrent.c index 7ecfb26cc..e1e06acf6 100644 --- a/nuttx/sched/task_deletecurrent.c +++ b/nuttx/sched/task_deletecurrent.c @@ -115,9 +115,12 @@ int task_deletecurrent(void) * 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 * 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; /* Move the TCB to the specified blocked task list and delete it */ @@ -143,7 +146,6 @@ int task_deletecurrent(void) * the lockcount on rctb. */ - DEBUGASSERT(rtcb->lockcount > 0); rtcb->lockcount--; return OK; } |