On Mon, 2006-08-21 at 13:47 +0200, Dmitry Adamushko wrote: > From: > Dmitry Adamushko > <[EMAIL PROTECTED]> > To: > xenomai-core@gna.org > Subject: > [Xenomai-core] [patch, minor] > xnpipe_recv and > xntimer_get_timeout_periodic() > Date: > 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 > 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. >
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, thanks. -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
