From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Paul Guo <paulguo(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Use nanosleep() for pg_usleep() on Unix/Linux? |
Date: | 2016-09-11 15:26:15 |
Message-ID: | 24848.1473607575@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Paul Guo <paulguo(at)gmail(dot)com> writes:
> I happened to read the pg_usleep() code recently. I'm wondering
> if we could implement it using the posix function nanosleep(),
> instead of by select().
That actually looks like a pretty good idea. Some research says that
nanosleep() is defined in SUSv2, our usual baseline for Unix features;
and it appears to be implemented and work per spec on even my oldest
buildfarm critters. So portability looks like a non problem.
It would be nice to have two versions of pg_usleep, one where handling
of a signal was guaranteed to terminate the wait and one where it was
guaranteed not to, rather than the current no-promises situation.
It looks like we could have that on the Unix side using nanosleep(),
but it's not clear to me whether we can do the second case on Windows.
> nanosleep() is designed with higher time resolution, besides it provide
> remaining time if is interrupted by signal so that pg_usleep() could
> be implemented more accurately.
> or combine with clock_gettime() to control the sleep time more accurately.
I do not think we really care about sub-microsecond sleep resolution.
But it would be good if we could implement a sleep that would be
approximately the requested length even with signals received meanwhile.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2016-09-11 15:47:21 | Re: Tuplesort merge pre-reading |
Previous Message | Tom Lane | 2016-09-11 14:34:57 | Re: [PATCH] Alter or rename enum value |