UnigramDev/Unigram/develop • c883cf7 • 1 files, +72/-3
Queue call transitions instead of blocking on the system call

TransitionToRequestingOrRinging blocked on InitializeSystemCallAsync, which
awaits the WinRT call reservation. VoipCoordinator.Handle calls Update from
inside its _activeLock on the TdReceive thread, and the VoipCall constructor
reaches the same transition, so the lock was held for the whole reservation —
including RequestNewIncomingCall and its 120 second ringing timeout. The UI
thread takes that lock through VoipCoordinator.ActiveCall, read from MainPage
and from the CallAccept and CallReject shortcuts, so it froze while a call was
being set up.

Awaiting alone would have introduced a worse problem. The block was also
ordering: a discard arriving while the reservation was in flight would reach
DisposeImpl with _systemCall still null, so nothing released it, and the
reservation completing afterwards would leave Windows showing an incoming call
that could no longer be ended.

Update now enqueues and returns, and a single pump applies transitions one at a
time in the order TDLib reported them. That keeps the ordering the block
provided while holding _activeLock only until the first await. The failure
handling matters: the catch sits inside the drain loop so one bad transition
cannot strand the rest, and _transitioning is cleared on the only exit, since a
call that stops draining would never reach Discarded.

UpdateImpl is otherwise the previous body unchanged, including its unlocked
read of _state, which races with OnStateUpdated and is left for its own change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 2180a5e • 1 files, +68/-19
Reserve the group call system call outside the constructor

All three VoipGroupCall constructors blocked on InitializeSystemCallAsync, and
VoipCoordinator runs each of them inside its _activeLock. The UI thread takes
that lock through VoipCoordinator.ActiveCall, read from MainPage and from
ChatGroupCallHeader, so it froze for the length of the reservation. The
ThreadPool.QueueUserWorkItem already wrapping those constructions kept the block
off the UI thread but did nothing about the lock.

Constructors cannot await, so the tail of each one moves into JoinAsync or
JoinConferenceAsync, started by the constructor and running after it returns.
The lock is then held only for field initialization. Ordering within the tail is
unchanged: reserve, create the window, then rejoin.

Leaving before the reservation completes needs handling that blocking made
unnecessary. Dispose would run with _systemCall still null, release nothing, and
the reservation completing afterwards would leave Windows holding a call that
can no longer be ended. Both paths check _isClosed once they have it and release
it themselves. _isClosed becomes volatile, since it is now read after an await
on a different thread from the one that sets it.

Dispose's system call teardown is extracted to DisposeSystemCall so the normal
and abandoned paths release it identically.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram