4 ms·
pg_usleep(1000L); Virtually any time you put a fixed sleep in your program, it's going to be wrong. It is either too long or too short, and even if it is perfe
by gsliepen 1y ago
pg_usleep(1000L);
Virtually any time you put a fixed sleep in your program, it's going to be wrong. It is either too long or too short, and even if it is perfect, there is no guarantee your program will actually sleep for exactly the requested amount of time. A condition variable or something similar would be the right thing to use here.
Of course, if this code path really is only taken very infrequently, you can get away with it. But assumptions are not always right, it's better to make the code robust in all cases.
- delusional 1y ago> there is no guarantee your program will actually sleep for exactly the requested amount of time This is technically true, but in the same way that under a preemptive operating system there's no guarantee that you'll ever be scheduled. The sleep is a minimum time you will sleep for, beyond that you already have no guarantee about when the next instruction executes.
- dwattttt 1y agoSpurious wakeups enters the chat.
- quietbritishjim 1y agoAny reasonable sleep API will handle spurious wake ups under the hood and not return control.
- Joker_vD 1y agoIt will also ignore those pesky signals and restart the sleep :) On a more serious note, any reasonable sleep API should either report all wake ups, no matter the reason, or none except for the timeout expiration itself. Any additional "reasonable" filtering is a loaded footgun because different API users have different ideas of what is "reasonable" for them.
- deleted 1y ago[deleted]
- anarazel 1y agoThe usleep here isn't one that was intended to be taken frequently (and it's taken in a loop, so a too short sleep is ok). As it was introduced, it was intended to address a very short race that would have been very expensive to avoid altogether. Most of the waiting is intended to be done by waiting for a "transaction lock". Unfortunately somebody decided that transaction locks don't need to be maintained when running as a hot standby. Which turns that code into a loop around the usleep... (I do agree that sleep loops suck and almost always are a bad idea)
- OptionOfT 1y agoIf I were reviewing that code I would've asked if they tried yielding. Same effect, but doesn't delay when there is no one to yield to.
- aspbee555 1y agoI was working through some ffmpeg timing stuff and the ai kept insisting on putting in sleep functions to try and "solve" it