This got me thinking about continuations, where a blocking sleep
just before a return to user mode would specify a function to call
(without running in the task's context and hence fast). This has
been discussed before, I think, and it wasn't thought to be worth it.
That's led me to another thought though: the sleep_on could specify
a function(+argument) to be called at wake_up time. The advantage
that the function is called without having to schedule the task is
still kept but there's no disavantage of complexity or code shuffling
as there is for getting the call_continuation pushed to the end of
the function that sleeps. A task that wanted to be awoken with high
priority would do something like
static void raise_priority(void *task) {
((struct task_struct *)task)->priority += delta;
}
sleep_on_plus(&foo_wait, raise_priority, current);
and wake_up would be changed to do the callback where necessary.
Since the callback is done in the context of the task doing the
wake_up there's no delay between wake_up and when the task is
finally scheduled and I can imagine that being rather useful.
It would need to be done without increasing the overhead of wake_up
unacceptably. Currently, wake_up does
if ((p->state == TASK_UNINTERRUPTIBLE) ||
(p->state == TASK_INTERRUPTIBLE))
wake_up_process(p);
so could there possibly be another TASK_INTERRUPTIBLE_PLUS_CALLBACK
state or maybe have a bitmask instead
if (p->state & TASK_WAITING) ...
or is there some other way of checking for the existence of a
callback request cheaply? Quite a lot of kernel code already "knows"
about TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE but almost all of
that is simply setting the current->state which would continue to
work anyway.
--Malcolm
-- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Unix Systems Programmer Oxford University Computing Services