#3182 closed defect (fixed)
CLOCK_REALTIME timeout implementation is not POSIX compliant
Reported by: | Sebastian Huber | Owned by: | Sebastian Huber |
---|---|---|---|
Priority: | normal | Milestone: | 5.1 |
Component: | posix | Version: | |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description (last modified by Sebastian Huber)
Changes of the CLOCK_REALTIME must trigger absolute timeouts. This is not the case. There is no test for this in RTEMS.
Change History (30)
comment:1 Changed on 10/12/17 at 17:34:48 by Joel Sherrill
comment:2 Changed on 10/13/17 at 08:07:57 by Sebastian Huber
See also:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_settime.html
Test case (runs on Linux as root):
https://lists.rtems.org/pipermail/devel/2017-October/019186.html
comment:3 Changed on 10/13/17 at 08:08:28 by Sebastian Huber
Description: | modified (diff) |
---|
comment:4 Changed on 10/17/17 at 06:31:01 by Sebastian Huber <sebastian.huber@…>
In [changeset:"bf2a53d272107b8b224b1a48694da24d2d042442/rtems" bf2a53d2/rtems]:
comment:5 Changed on 10/17/17 at 06:31:14 by Sebastian Huber <sebastian.huber@…>
In [changeset:"91ce012ced085682e271af4bf33e112dc968d4b9/rtems" 91ce012c/rtems]:
comment:6 Changed on 10/17/17 at 11:57:07 by Sebastian Huber <sebastian.huber@…>
In [changeset:"9a583a94d372afba5a2796189b40f8efa16bcfd4/rtems-libbsd" 9a583a9/rtems-libbsd]:
comment:7 Changed on 10/19/17 at 12:47:54 by Sebastian Huber
According to POSIX we have for clock_nanosleep():
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
"If, at the time of the call, the time value specified by rqtp is less than or equal to the time value of the specified clock, then clock_nanosleep() shall return immediately and the calling process shall not be suspended."
Would it be all right to perform a sched_yield() in this case? This would make the implementation of the thread queue enqueue a bit easier.
comment:8 Changed on 10/19/17 at 13:03:51 by Joel Sherrill
I think having a time in the past yield is a good solution. Just add it to the documentation in the right spots.
comment:9 Changed on 10/19/17 at 13:06:45 by Sebastian Huber
A yield may lead to a pre-emption. I am not sure if this is all right with respect to the "return immediately and the calling process shall not be suspended".
comment:10 Changed on 10/19/17 at 13:40:08 by Sebastian Huber
Why is nanosleep() not implemented as clock_nanosleep(CLOCK_REALTIME, 0, rqtp, rmtp)?
comment:11 Changed on 10/19/17 at 13:44:02 by Joel Sherrill
History. nanosleep has been there much longer.
comment:12 Changed on 10/24/17 at 08:20:14 by Sebastian Huber <sebastian.huber@…>
In [changeset:"d85c94c0d292023b78320fca14956262de7f40c6/rtems" d85c94c0/rtems]:
comment:13 Changed on 10/24/17 at 08:20:25 by Sebastian Huber <sebastian.huber@…>
In [changeset:"028786263f8e23d85723e0751f132401cd4dbc44/rtems" 02878626/rtems]:
comment:14 Changed on 10/24/17 at 08:20:37 by Sebastian Huber <sebastian.huber@…>
In [changeset:"27cfe7c86ba0801f4961871869ec4e691ca694f3/rtems" 27cfe7c/rtems]:
comment:15 Changed on 10/24/17 at 08:20:49 by Sebastian Huber <sebastian.huber@…>
In [changeset:"e0dc6efcf0f7d6da2cc0ac08303e1382f6bf4e69/rtems" e0dc6ef/rtems]:
comment:16 Changed on 10/24/17 at 08:21:01 by Sebastian Huber <sebastian.huber@…>
In [changeset:"381ef5c83393d3707cf74f40f1edc2d0404c3ee6/rtems" 381ef5c/rtems]:
comment:17 Changed on 10/24/17 at 08:21:13 by Sebastian Huber <sebastian.huber@…>
In [changeset:"ecef36987538fe7daf033c0c9344413355d615b1/rtems" ecef3698/rtems]:
comment:18 Changed on 10/24/17 at 08:21:25 by Sebastian Huber <sebastian.huber@…>
In [changeset:"adaf5c232e680630e77c697fafa31dff4f3e1d24/rtems" adaf5c23/rtems]:
comment:19 Changed on 10/24/17 at 08:21:36 by Sebastian Huber <sebastian.huber@…>
In [changeset:"d16d07fbb82132e185835382201243c5eab5417a/rtems" d16d07f/rtems]:
comment:20 Changed on 10/24/17 at 08:21:48 by Sebastian Huber <sebastian.huber@…>
In [changeset:"7ed377bc69e8cf96b989018322dc43bc0f2d2e36/rtems" 7ed377b/rtems]:
comment:21 Changed on 10/24/17 at 08:22:00 by Sebastian Huber <sebastian.huber@…>
In [changeset:"cea5ff700166a24b5da300cf0aa6884164600ed3/rtems" cea5ff7/rtems]:
comment:22 Changed on 10/24/17 at 08:22:12 by Sebastian Huber <sebastian.huber@…>
In [changeset:"b13ec804763d8f428161a50fd1846d567982ed4b/rtems" b13ec80/rtems]:
comment:23 Changed on 10/24/17 at 08:22:24 by Sebastian Huber <sebastian.huber@…>
In [changeset:"57479629094a7b1a13a6fb03c3162cb53367022c/rtems" 5747962/rtems]:
comment:24 Changed on 10/24/17 at 08:22:36 by Sebastian Huber <sebastian.huber@…>
In [changeset:"6de1f92121f947f9c379747d66135fd8a500d0f5/rtems" 6de1f92/rtems]:
comment:25 Changed on 10/24/17 at 08:22:48 by Sebastian Huber <sebastian.huber@…>
In [changeset:"1666ffe535b5e2ca801dafa13437fc2bd041cd3a/rtems" 1666ffe5/rtems]:
comment:26 Changed on 10/24/17 at 08:23:00 by Sebastian Huber <sebastian.huber@…>
In [changeset:"c31058947491ca319c901040219be39e4f8155b6/rtems" c3105894/rtems]:
comment:27 Changed on 10/25/17 at 05:54:30 by Sebastian Huber <sebastian.huber@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
In [changeset:"c5161ee2f30e124c3190694962d2e1aeea5b102c/rtems-docs" c5161ee/rtems-docs]:
comment:28 Changed on 11/09/17 at 06:27:14 by Sebastian Huber
Milestone: | 4.12.0 → 5.1 |
---|
Milestone renamed
comment:29 Changed on 03/22/18 at 07:43:06 by Sebastian Huber <sebastian.huber@…>
In [changeset:"3da2f4711d3691716b9f0b468978fe43cdc91df8/rtems" 3da2f471/rtems]:
comment:30 Changed on 03/22/18 at 08:06:14 by Sebastian Huber <sebastian.huber@…>
In [changeset:"7353422fc350c29f08a757696d25fdb38a297bef/rtems" 7353422f/rtems]:
I think this only can be used via clock_nanosleep() or a timeout on a condition variable.
Do both not wakeup after a time change on CLOCK_REALTIME?
Are there tests for this?