Jan Kiszka wrote:
Hi,
I think this line will cause troubles when the timer wraps around its
limit:
http://www.rts.uni-hannover.de/rtai/lxr/source/skins/rtai/task.c?v=cvs-4.x-fusion#L919
What about the attached patch? Every delay >= 2^63 will be accounted as
a timeout miss. Should be enough for practical scenarios.
The posix skin handles absolute to relative timeout conversions
differently. It simply substracts (unsigned) the current time from
abstimeout.
I think the posix skin should switch to a similar scheme as well. The
posix spec demands such a timeout miss detection which is currently lacking.
Jan
PS: Following the way the timeout value takes into the nucleus, I
stumbled over this line:
http://www.rts.uni-hannover.de/rtai/lxr/source/nucleus/pod.c?v=cvs-4.x-fusion#L1341
The checks is redundant as long as this is intended to remains valid:
http://www.rts.uni-hannover.de/rtai/lxr/source/nucleus/timer.c?v=cvs-4.x-fusion#L250
Index: task.c
===================================================================
RCS file: /cvs/rtai/fusion/skins/rtai/task.c,v
retrieving revision 1.60
diff -u -p -r1.60 task.c
--- task.c 30 May 2005 14:02:04 -0000 1.60
+++ task.c 6 Jul 2005 13:52:41 -0000
@@ -900,7 +900,7 @@ int rt_task_sleep_until (RTIME date)
{
int err = 0;
- RTIME now;
+ STIME delay;
spl_t s;
if (xnpod_unblockable_p())
@@ -914,13 +914,13 @@ int rt_task_sleep_until (RTIME date)
/* Calling the suspension service on behalf of the current task
implicitely calls the rescheduling procedure. */
- now = xnpod_get_time();
+ delay = date - xnpod_get_time();
- if (date > now)
+ if (delay > 0)
{
xnpod_suspend_thread(&rtai_current_task()->thread_base,
XNDELAY,
- date - now,
+ delay,
NULL);
if (xnthread_test_flags(&rtai_current_task()->thread_base,XNBREAK))
