Dear Paolo,
I am currently switching my development environment from GNU/Linux to
XNU (OSX) and there appears a funny “scheduling” or time issue that leads
to a race-condition.
(Delay forMilliseconds: 500) wait
Can get stuck forever (e.g. the process.st testcase fails because of that). From
what I see this is happening.
_gst_sigalrm_at is getting called with a nsTime that is really close to the now
time (either because of scheduling or non linear time? I don’t know) but here
is what happens:
nsTime is 1429097745443176000
now is 1429097745442951000
this means deltaMilli will be 0 which leads to us “canceling” the timer instead
of setting it. My workaround is to make sure that tv_usec is never zero. Is this
acceptable? E.g. something like this?
diff --git a/libgst/sysdep/posix/timer.c b/libgst/sysdep/posix/timer.c
index c47ae91..10e0e92 100644
--- a/libgst/sysdep/posix/timer.c
+++ b/libgst/sysdep/posix/timer.c
@@ -121,8 +121,16 @@ _gst_sigalrm_at (int64_t nsTime)
struct itimerval value;
value.it_interval.tv_sec = value.it_interval.tv_usec = 0;
- value.it_value.tv_sec = deltaMilli / 1000;
- value.it_value.tv_usec = (deltaMilli % 1000) * 1000;
+ if (deltaMilli)
+ {
+ value.it_value.tv_sec = deltaMilli / 1000;
+ value.it_value.tv_usec = (deltaMilli % 1000) * 1000;
+ }
+ else
+ {
+ value.it_value.tv_sec = 0;
+ value.it_value.tv_usec = 1;
+ }
setitimer (ITIMER_REAL, &value, (struct itimerval *) 0);
}
}
_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Locked
