Date: Mon, 25 Aug 2025 06:54:05 +0200
> I wonder, are there any inherent reasons why we shouldn't have such
> function templates in the standard library? If so, I won't pursure
> writing a proposal. If it's just a case of "noone wanted them bad enough
> to write a proposal", I may go ahead.
I don't know the history, but how would those even be implemented? The
obvious issue is that if you try_lock_for one second, and spend 0.99s
on the first of three locks, you may just run out of time before
having locked them all. Should try_lock_for be per-lock, or should it
pre-compute and act like try_lock_until for each of the locks?
It would also seem much better if you could begin a try_lock_until
request for all mutexes simultaneously instead of blocking on one
mutex since that makes it more likely you will "make it in time", but
that would require the underlying mutexes to all have some
asynchronous locking API. Perhaps that would be the more important
first step in this process, not the try_lock_until wrapper.
> function templates in the standard library? If so, I won't pursure
> writing a proposal. If it's just a case of "noone wanted them bad enough
> to write a proposal", I may go ahead.
I don't know the history, but how would those even be implemented? The
obvious issue is that if you try_lock_for one second, and spend 0.99s
on the first of three locks, you may just run out of time before
having locked them all. Should try_lock_for be per-lock, or should it
pre-compute and act like try_lock_until for each of the locks?
It would also seem much better if you could begin a try_lock_until
request for all mutexes simultaneously instead of blocking on one
mutex since that makes it more likely you will "make it in time", but
that would require the underlying mutexes to all have some
asynchronous locking API. Perhaps that would be the more important
first step in this process, not the try_lock_until wrapper.
Received on 2025-08-25 04:54:22