functions that do not sleep and recovery points
akaz
akaz at utopia.com
Sat Jul 21 00:54:02 PDT 2012
Hi,
In Linux kernel programming, there are some parts that are not
allowed to sleep (to be rescheduled). For example: interrupt
handlers, softirqs and tasklets.
Using functions that can sleep (for example: malloc, semaphores,
regular mutexes - unlike spin_locks, etc.) is forbidden inside
the above code entities.
Currently, this is the responsibility of the programmer. I think
that the compiler itself (the gcc) cannot enforce this as it
cannot know for sure if a function may block (sleep) or no.
But, the question is:
- is there any mechanism in D (maybe @pure? @trusted?
@notsleeping? or something similar) that could guarantee that a
function cannot block? (and enforce that all the function called
from inside that function are not-blocking too). More generally,
to make such a property transitive and to enforce that?
A bit off-topic, there is another question, this time concerning
real-time programming: there are two basic strategies for error
recovery: forward-recovery (that means, raising an exception and
saving what can still be saved) and backward-recovery (that
means, going back in time/code to a recovery point and trying to
do the job again, maybe using an alternative algorithm).
The forward-recovery is classic in C++ and D. The
backward-recovery seems to not be so easy: exceptions can be used
to detect such an error, but the language itself does not
provides a way for establishing a recovery point (I think it
might be seen as a program snapshot) to go back to it and then
start again (while setting a flag to let "the future" know that
an error occurred).
Imagine: trying to compute using one fast algorithm but that
diverge easily -> failure. Then, roll back and try an alternative
algorithm, that is more intensive but convergence is guaranteed
etc. You have to know where to roll back. A simple goto will do
it?
Then, the second question is:
- is there any mechanism in D to provide recovery points?
Thank you.
More information about the Digitalmars-d-learn
mailing list