On Fri, 16 Jun 2000, George Anzinger wrote:
> Guess it depends on what you mean by process context. What I was saying
> is that they don't run in interrupt context, i.e. they are called from
> schedule. They do run on the current tasks stack and they are called by
> the scheduler with the interrupt system on. If they were to sleep, I
> expect that the current process would be the one to sleep. Granted this
> is a _BIG NO-NO_, but I don't think there is a check in place to stop
> it. So, how do we define process context or interrupt context?
In this case, we're talking about whether we're permitted to try to obtain
a semaphore - i.e. whether we're permitted to sleep. OK, we're not
actually running from a hardware IRQ handler, but we think of ourselves as
being in IRQ context because we're not allowed to do any (most?) of the
things that normal processes can but IRQs can't.
Getting back to the original problem - I suppose you could schedule a
timer which uses down_trylock() and reschedules itself if that fails -
but that's quite ugly.
-- dwmw2- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:14 EST