On Mon, 2006-08-21 at 13:47 +0200, Dmitry Adamushko wrote:
> Dmitry Adamushko
> <[EMAIL PROTECTED]>
> [Xenomai-core] [patch, minor]
> xnpipe_recv and
> Mon, 21 Aug 2006 13:47:00 +0200
> On Mon, 2006-08-21 at 12:47 +0200, Dmitry Adamushko wrote:
> > what about pipe-related change (I mean timeslice updating
> > xnpipe_recv()) ?
> It's basically useless, since xnsynch_sleep_on() handles the
> stealing case internally, and the loop in xnpipe_recv is fake
> 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.
Ok, I thought we were discussing a more general issue about a new
potential side-effect of the resource stealing feature.
> 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".
Definitely, yes. Please ignore my previous comment. I'll apply this one,
Xenomai-core mailing list