The task queue, by default, is only 8 tasks deep.  A task queue
overflow would cause the task not to execute.

-Joe

On 1/23/06, Martin Gercke <[EMAIL PROTECTED]> wrote:
> Ok,
>
> so there must be a limit for tasks that are waiting in the queue, right?
> If the loop is a running task then at the end of this task the waiting
> tasks should be run by the scheduler.
> Correct?
> I am just wondering why the receive-task isn't run at all.
> If the interrupt isn't directly processing the data and instead posting
> a task of course as you said the running task and all waiting tasks will
> be run first.
>
> Martin
>
>
> Joe Polastre wrote:
>
> >Because interrupts post tasks, and if a task is halting execution, you
> >never get the task posted by the interrupt.
> >
> >-Joe
> >
> >On 1/23/06, Martin Gercke <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Hmm,
> >>
> >>I don't really get that.
> >>Isn't an interrupt supposed to interrupt a running task immediately?
> >>Why is that not the case - instead of the loop there could be any other
> >>task running.
> >>What makes this example so special?
> >>
> >>Martin
> >>
> >>
> >>Joe Polastre wrote:
> >>
> >>
> >>
> >>>Remove the loop and use Timers instead.  You have completely
> >>>eliminated any concurrency in the system with that loop.
> >>>
> >>>-Joe
> >>>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>

_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to