I'm open to going back and changing other things like roundingIncrement, fractionalSecondDigits, and Temporal.PlainDate.from({ year: 2024.5, month: 7.5, day: 29.5 }) to reject non-integral inputs but I'd like us to explicitly approve that now, rather than me coming back to a following meeting with a PR

What about the other conventions?

Well I was wondering if ptomato had an opinion on the “not coercing at all” one with respect to Temporal

I don't have much of an opinion, but what I don't want is to have to come back to the next meeting with a PR

Rbuckton: you are making a very different feature request from this coercion discussion. Probably this is best for the temporal v2 bucket

littledan ptomato this meeting has some extra time if you want to put together a last-minute item for dropping coercion from temporal, though it is very far past the deadline so it would need to be conditional approval

This is reminding me of the coffee filter in/out discussion in Nov 2019. Folk are seeing the pause N from both sides. Shu wants small N to mean a longer pause.

I think we have agreement on the normative: the pauses between spins get bigger and bigger before going to sleep.

pauses get bigger and smaller in mature implementations. ideally you want to have the behavior that kris explained, but implementations like linux for example also have a signal of "starvation" which can cause the delay to get longer as well.

i am just confused what there is to disagree on, there is literally no observable behavior

i will remove the text about the backoff and any particular relation between the pause length and the iterationNumber argument

he said JSC will likely ignore it, which is certainly fine

but "just ignore it" doesn't sound like something tuned for M-chips; it sounds like not engaging with the question

why would we try to align on how to interpret a hint?

well, we'd want to align on, engines feeling like they can interpret this as a hint, rather than that it's just something to ignore

I assume the CPU architecture has some semantic meaning for the hint?

Atomics.pause is purely a CPU architecture dependent operation. A conforming implementation is welcome to ignore iterationCount and return immediately if it so chooses, though that is the least efficient approach as it most likely results in thread starvation and does not improve contention.
An efficient implementation of pause will use the iterationCount to avoid thread starvation and optimize contention by periodically introducing an asm pause or similar instruction based on whatever information is relevant for that architecture. The main goal is to avoid spinning longer than you would have had to wait for a context switch/kernel transition. These optimizations can include, but are not limited to:

• Only pausing every n iterations
• issuing a pause more or less frequently the longer we've been spinning
• issuing a pause more or less frequently based on how frequently we've been spinning
• issuing a pause more or less frequently as you approach an amount of time since you started spinning that would be equivalent to the time spent waiting for a context switch.

Would Waldemar be satisifed with bigger-number-longer-wait? Then let the engine handle that to match the VM’s CPU instructions, eg smaller-number-longer-wait?

I don't think "bigger-number-longer-wait" is correct, TBH.

It’s the most intuitive, and it’s how I’ve written async-retires before.

I think the implementation is still left to the engine, but the hint now has a known meaning. Whether it uses exponential/quadratic/etc, whether the CPU expect big or large numbers, is left for the implementation.

Sync retries sounds very similar to async retries…

I think that's the worst outcome

I guess my concern is that one workload wants longer and longer waits. And others want shorter and shorter waits

Then we should just not have anything passed by the JS users and the JS engine can infer the loop count if they really want to

https://docs.rs/tokio/latest/tokio/sync/struct.Semaphore.html <- thing called semaphore in a non-js language, with a broadly similar api to our proposal. we will investigate other names though! :D

In esfx, I use Semaphore for the thread coordination primitive, and AsyncSemaphore for the async coordination (non multi-threaded) primitive, though AsyncSemaphore is still a simple coordination primitive and has now knowledge of async iteration.

keith_miller: that's fair, and the concession is that you can't actually express that in JS code

keith_miller: but it might not be a linear/superlinear relationship at all, like what Ron was saying with "wait every 10th iteration" or something

to me a semaphore are those big flags the dude waves on the top of an aircraft carrier

https://en.cppreference.com/w/cpp/thread/counting_semaphore
https://learn.microsoft.com/en-us/dotnet/api/system.threading.semaphore?view=net-8.0
https://learn.microsoft.com/en-us/dotnet/api/system.threading.semaphoreslim?view=net-8.0
https://docs.python.org/3/library/asyncio-sync.html#asyncio.Semaphore
https://docs.python.org/3/library/asyncio-sync.html#boundedsemaphore
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Semaphore.html
https://esfx.js.org/esfx/api/threading-semaphore.html?tabs=ts (NOTE: my implementation, though not heavily used)
https://esfx.js.org/esfx/api/async-semaphore.html?tabs=ts (NOTE: my implementation, though not heavily used)

Given this list, Semaphore really seems like the right name, though I'm fine with CountingSemaphore also. shu wdyt about this list?

interface Governor {
  acquire(): Promise<GovernorToken>;
}

interface GovernorToken {
  release(): void;
  // or
  [Symbol.dispose](): void;
}

and, not or

how about tryAcquire

how about tryAcquire

like, it would be a blocking void acquire() that can't be called on the main thread

how attached are you to the void part? the fact that you can release a thing you didn't previously acquire seems like a non-essential (and bad) part of textbook C semaphore implementation

To use the train or ship "Semaphore" metaphor, that's like waiving a flag to let a user in, and then that user gets to waive the flag to let the next user in.

wait ron you're arguing that there should be a release method that does not require a previously acquired capability?

do <2 minutes remain?

i am new to someone arguing that linear types are bad

The goal seems reasonable. But wouldn't it just be implemented with extra pauses in the JIT?

if i write a mutex implementation in JS, i don't want the contention fast path to be waiting for longer/shorter depending on whether you're in the interpreter or in the JITs

You're assuming a single correct usage, and there is not a single correct usage.

I don’t understand why you’d encoruage putting dispose on the manager instead of the instance.

https://matrixlogs.bakkot.com/TC39_Delegates/2024-07-29#L327

Like what if I like to write my loops as for (I = spinCount; I--;) Atomics.yield(i);

If the concern is "I sometimes want to do something other than that, and I think of that other thing as being called Semaphore", that's a fair piece of feedback to support the rename, but not to support a different API.

why do you draw a line between binary and counting semaphores for this api?

i think it is slightly less ergonomic because i think monotonic decreasing wait time is the right default interpretation

i see. my personal experience using counting and binary semaphores in rust (which is just tokio::sync::Semaphore, its the same api) is that it works well for both cases, and it has helped to reduce bugs in more complex use cases like the ones you seem to be concerned about.

Would Waldemar be satisifed with bigger-number-longer-wait? Then let the engine handle that to match the VM’s CPU instructions, eg smaller-number-longer-wait?

waldemar: after chatting with keith_miller i think i am perfectly happy with spelling out the bigger-number-longer-wait semantics. but i'd like to caution that since timing is not observable behavior, an implementation can still choose another interpretation of the hint as an as-if optimization.

would spelling out bigger-number-longer-wait satisfy your concerns?

bakkot: i did not have the capacity to fully pay attention to the governor thing and the Atomics.pause discussion, but a fully generic "unlock token" concept seems elegant. but the gut reaction i have is (wait for it) performance concerns about the allocations of these tokens in hot paths -- ideally i'd like to not bottleneck finer grained locking architectures

I think that having semaphore.acquireAndCall(fn) for the hot paths would make sense. though I'd guess in hot paths the token objects would never leave the nursery and therefore(?) not be that expensive?