On Mon, 2006-08-21 at 12:47 +0200, Dmitry Adamushko wrote:
> what about pipe-related change (I mean timeslice updating in
> xnpipe_recv()) ?

It's basically useless, since xnsynch_sleep_on() handles the resource
stealing case internally, and the loop in xnpipe_recv is fake actually.
Think of it as a goto statement in disguise.

It has nothing to do with "resource stealing" (in terms of synch.c). The synch object is not PIP at all.

task1 : blocked in xnpipe_recv()

task2 : xnpipe_send() ---> wakes up task1 ---> task1 is waiting to be scheduled in

task3 [prio > task2.prio] : gets CPU and calls xnpipe_recv()

   task3 gets a message so state->inq is empty now.


task2 : calls getq(&state->inq) which is NULL now (if there were no more messages)

calls xnsynch_sleep_on() again with the initial "timeout".

> --

> Best regards,
> Dmitry Adamushko

Best regards,
Dmitry Adamushko

Xenomai-core mailing list

Reply via email to