فی الحال ٹیسٹنگ جاری ہے: مکمل ہونے پر GitHub کوڈ کھول دیا جائے گا۔

B · مصروف

ساختrefresh

Acquire request (A) key queue یا global key/waiter/pending/memory admission حد پر ہونے سے قبول نہیں ہوئی۔ اس request نے یقینی طور پر lock حاصل نہیں کیا اور frame invalid نہیں تھا۔

owner request کا echoed correlator ہے جس سے rejected acquire معلوم ہوتا ہے (matching rules

Client handling

Official clients correlated B فوراً Busy/Capacity error کے طور پر caller کو دیتے ہیں اور وہی logical acquire internally resend نہیں کرتے۔ Retry کے لیے caller overall deadline اور backoff طے کر کے نئے owner سے نیا acquire explicitly شروع کرتا ہے۔

حقیقتاً ملا B non-acquire ثابت کرتا ہے، اس لیے الگ نیا call safe ہے۔ Response نہ ملے send کو B نہ سمجھیں؛ وہ Indeterminate ہے۔

بائٹ نوٹیشن: op ایک ASCII حرف ہے، owner بائنری (u64، big-endian) ہے، اور key UTF-8 متن ہے (متغیر لمبائی، ڈھانچے میں N کے طور پر)۔ آخری \n 0A ہے۔ فکسڈ ہیڈر بائنری قدر ہے جس میں 0x0A آ سکتا ہے، اس لیے نئی لائن تلاش کرنے سے پہلے بائٹ کی تعداد کے مطابق پہلے کھپانا ہوگا۔

بہاؤ

کلائنٹ
سرور
A · حصول (key · owner)
اس کلید کی قطار max_waiters تک پہنچ گئی
B · مصروف (owner echo)
Busy واپس — caller نیا logical acquire طے کرے
A · نیا acquire (اختیاری retry)
جگہ ہونے پر → A · acquired (token)
درخواستجواب

یہ limits memory guardrails ہیں۔ Daemon OOM سے پہلے نئے acquires reject ہوتے ہیں اور exact-token release، approved responses، cleanup اور Raft recovery کے لیے resources محفوظ رہتے ہیں۔ key_busy، per_key_limit، global_overload جیسے اسباب wire نہیں بلکہ metrics/logs میں الگ ہوتے ہیں۔