From: Manfred Spraul <manfred@colorfullife.com>
To: dwmw2@redhat.com, andrewm@uow.edu.au
Cc: linux-kernel@vger.kernel.org
Subject: flush_scheduled_tasks() question
Date: Sun, 28 Jan 2001 17:26:08 +0100 [thread overview]
Message-ID: <3A744820.2C4C94F6@colorfullife.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Is is intentional that tummy_task is not initialized?
Ok, it won't crash because the current __run_task_queue() implementation
doesn't call tq->routine if it's NULL, but IMHO it's ugly.
Additionally I don't like the loop in flush_scheduled_tasks(), what
about replacing it with a locked semaphore (same idea as vfork)?
I've attched an untested patch.
--
Manfred
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1888 bytes --]
--- context.c.orig Sun Jan 28 17:02:35 2001
+++ context.c Sun Jan 28 17:09:24 2001
@@ -22,7 +22,6 @@
static DECLARE_TASK_QUEUE(tq_context);
static DECLARE_WAIT_QUEUE_HEAD(context_task_wq);
-static DECLARE_WAIT_QUEUE_HEAD(context_task_done);
static int keventd_running;
static struct task_struct *keventd_task;
@@ -97,7 +96,6 @@
schedule();
remove_wait_queue(&context_task_wq, &wait);
run_task_queue(&tq_context);
- wake_up(&context_task_done);
if (signal_pending(curtask)) {
while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0)
;
@@ -119,31 +117,24 @@
* The caller should hold no spinlocks and should hold no semaphores which could
* cause the scheduled tasks to block.
*/
-static struct tq_struct dummy_task;
-void flush_scheduled_tasks(void)
+static void up_semaphore(void* sem)
{
- int count;
- DECLARE_WAITQUEUE(wait, current);
+ up((struct semaphore*)sem);
+}
- /*
- * Do it twice. It's possible, albeit highly unlikely, that
- * the caller queued a task immediately before calling us,
- * and that the eventd thread was already past the run_task_queue()
- * but not yet into wake_up(), so it woke us up before completing
- * the caller's queued task or our new dummy task.
- */
- add_wait_queue(&context_task_done, &wait);
- for (count = 0; count < 2; count++) {
- set_current_state(TASK_UNINTERRUPTIBLE);
+void flush_scheduled_tasks(void)
+{
+ DECLARE_MUTEX_LOCKED(sem);
+ struct tq_struct wakeup_task;
- /* Queue a dummy task to make sure we get kicked */
- schedule_task(&dummy_task);
+ wakeup_task.routine = up_semaphore;
+ wakeup_task.data = &sem;
+ /* Queue a dummy task to make sure we get kicked */
+ schedule_task(&dummy_task);
- /* Wait for it to complete */
- schedule();
- }
- remove_wait_queue(&context_task_done, &wait);
+ /* Wait for it to complete */
+ down(&sem);
}
int start_context_thread(void)
next reply other threads:[~2001-01-28 16:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-28 16:26 Manfred Spraul [this message]
2001-01-29 9:53 ` flush_scheduled_tasks() question David Woodhouse
2001-01-29 10:15 ` Manfred Spraul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A744820.2C4C94F6@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=andrewm@uow.edu.au \
--cc=dwmw2@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox