Thread parking for Kotlin/Common

[bbrockbernd]

Allows to pause and resume thread execution. On native platforms it is based on pthread_cond_wait, on JVM it uses LockSupport.

Threads can be pre unparked (calling unpark before park cancels the parking operation). And thread can be parker with a timeout.

Suspend the current thread by calling:

ParkingSupport.park(timeout: kotlin.time.Duration)
// or
ParkingSupport.parkUntil(deadline: TimeMark)
// or park without timout
ParkingSupport.park(kotlin.time.Duration.INFINITE)

Resume a thread by calling:

ParkingSupport.unpark(handle: ParkingHandle)

Get current thread reference by calling:

val handle = ParkingSupport.currentThreadHandle()

[dkhalanskyjb]

Probably makes more sense to assert in the code that the negative number of nanos never even enters addNanosToSeconds. No reason to test the code path that will never be taken.

[dkhalanskyjb]

I'd also print the contents of https://www.man7.org/linux/man-pages/man3/errno.3.html

[dkhalanskyjb]

A stronger version of the check: if the value does not clamp, the (updatedTime - currentTime) == nanos / 1_000_000_000; if the value clamps, it's because as a Long value, it would exceed an Int. This describes what we want from addNanosToSeconds more precisely. As is, when I write internal fun Long.addNanosToSeconds(nanos: Long): Long = this + nanos / 2_000_000_000, for example, no tests fail.

[dkhalanskyjb]

The implementation is almost ready to go, I believe. Good work! Only some documentation fixes are left, and there's maybe potential to simplify the code.

I haven't looked at the tests yet, though.

[dkhalanskyjb]

Question: can the code be simplified if we take parkUntil as the fundamental operation and then implement parkNanos on top of it? The idea is that POSIX exposes something that's similar to parkUntil already, so waitWithDeadline may be easier to write than timedWait, and LockSupport.parkUntil may be somewhat simpler than LockSupport.parkNanos (due to the simpler "is it time to exit yet?" check).

[bbrockbernd]

AFAIK, a TimeMark is not directly convertible to nanos from epoch. The only way I have found so far is by somehow getting the current time from epoch and subtracting TimeMark.elapsedNow (which is converting to duration.)

Additionally, to get current time in nanos from epoch (on native) we either need kotlinx-datetime which doesn't seem to be more granular than milliseconds. Or rely on clock_gettime from POSIX and convert TimeMark to duration, which is what we currently do.

But I might be missing some api?

[dkhalanskyjb]

You're right, TimeMark does not expose its relationship to absolute time.

kotlin.time.Instant (which used to be in kotlinx-datetime) does provide nanosecond precision, and in fact, delegates to clock_gettime. So, with Kotlin 2.1.20, which introduced Instant, it's possible to do this (pseudocode):

fun parkUntil(deadline: TimeMark) {
  val estimatedTargetTime: Instant = Clock.System.now() - deadline.elapsedNow()
  sleepUntil(instant.epochSeconds, instant.nanosecondsOfSecond)
}

The problem is, we're not on Kotlin 2.1.20, so we indeed don't have access to Instant.

But! This gets me thinking: why do we need an Instant at all? It's semantically wrong. In fact, we may have a subtle bug.

See, CLOCK_REALTIME (https://man7.org/linux/man-pages/man2/clock_gettime.2.html), kotlin.time.Instant, and by default, pthread_cond_timedwait (https://docs.oracle.com/cd/E19120-01/open.solaris/816-5137/gfvid/index.html) all have to do with system time, that is, what your clock in the corner of the screen says. This clock may get out of sync, and then get back in sync when your system queries the Internet for the up-to-date time.

It seems like the following may happen:

• At 12:13:59, we park for three seconds. We are waiting until 12:14:02.
• One second later, at 12:14:00, we query the Internet and see that our clock is too fast and is into the future by two seconds.
• One second later, it's 12:13:59 again.
• Then, three seconds later, it's finally 12:14:02... but five seconds have passed.

TimeSource.Monotonic, though, works with elapsed time, which is what we want.

Proposed fix: https://stackoverflow.com/a/14397906. With this, we don't need to extract epoch time at all.

What do you think?

[bbrockbernd]

That is quite the edge case! However, the fix proposed relies on pthread_condattr_setclock which is not available on darwin.

Also, I am wondering, is the kotlin TimeSource.Monotonic synced to the posix CLOCK_MONOTONIC?

[dkhalanskyjb]

That is quite the edge case!

Indeed, but I'd estimate that every day, someone somewhere encounters this. Having clocks drift by a couple of seconds per day is typical.

not available on darwin.

Oh, ok. If you also can't think of a way to fix this there, we need to at least document that on Native, the system clock is used and is susceptible to such issues.

Also, I am wondering, is the kotlin TimeSource.Monotonic synced to the posix CLOCK_MONOTONIC?

Kotlin/Native delegates to C++'s std::conditional<high_resolution_clock::is_steady, high_resolution_clock, steady_clock>. I don't know how our C++ standard library implements those, but it's not necessarily a wrapper around POSIX.