SLEEP accuracy
Bug #308950 reported by
Nikodemus Siivola
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Won't Fix
|
Low
|
Unassigned |
Bug Description
The more interrupts arrive the less accurate SLEEP's timing gets.
(time (sb-thread:
(prog1 (sb-thread:
Changed in sbcl: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in sbcl: | |
importance: | Medium → Low |
Changed in sbcl: | |
assignee: | nobody → Nikodemus Siivola (nikodemus) |
status: | Confirmed → In Progress |
To post a comment you must log in.
This is a known problem with nanosleep(2), the manpage on linux describes it in detail. Because of this, clock_nanosleep(2) was born and it should be portable. Now the only issue I see with clock_nanosleep (which applies to nanosleep as well) is that it's not specified to be async signal safe. So either we can live with potential deadlocks if a timer, or interrupt-thread uses sleep or we have to fall back on a select based implementation.
Come to think of it, the deadline mechanism is also affected and since a lot of functions only support timeouts and not deadlines (select(), just to name a showstopper) it's not possible to solve this in general. But is should be possible to fix the async signal safety part by using select() with a timeout.