Rust Async Blocking، Rayon اور جدید ایپلیکیشنز

Workstation تکنیکی بریف: کیوں Rust بہت سی جدید ایپلیکیشنز — APIs، edge، agents اور CI/CD پلیٹ فارمز — کے لیے مضبوط ڈیفالٹ رہتا ہے، اور async runtime کے ساتھ CPU-bound کام کو درست طریقے سے کہاں رکھیں۔ ہم Alice Ryhl کے مضمون Async: What is blocking? سے متاثر ہیں (لفظی نقل نہیں)، خاص طور پر Rayon رہنمائی۔ ساتھی: بلاگ · ثبوت: Polyglot Benchmarks · متعلقہ: polyglot مضمون۔

1. پروڈکشن اسٹیٹس میں اہم Rust فوائد

جدید ایپلیکیشن پورٹ فولیو شاذ و نادر ہی یک لسانی ہوتے ہیں۔ پھر بھی کچھ سطحیں Rust کی خصوصیات کو انعام دیتی ہیں:

• بغیر GC jitter کے میموری سیفٹی — ownership اور borrowing کمپائل وقت پر use-after-free اور data races پکڑتے ہیں؛ latency-sensitive راستے stop-the-world سے بچتے ہیں۔
• قابلِ پیش گوئی کارکردگی — zero-cost abstractions اور allocation پر باریک کنٹرول Rust کو گرم API راستوں اور edge transforms پر مسابقتی بناتے ہیں۔
• ڈھانچے کے ساتھ بے خوف concurrency — Send/Sync اور async ماحولیہ (Tokio، async-trait پیٹرنز، channels) fan-out کے تحت اسکیل کرنے والے ڈیزائن کی حوصلہ افزائی کرتے ہیں۔
• قابلِ تعینات بائنریز — تقریباً static آرٹیفیکٹس گیٹ ویز، agents اور CI/CD sidecars کے کنٹینرز آسان بناتے ہیں۔
• polyglot اسٹیٹس میں interop — FFI، Wasm اور HTTP Rust کو Go، Python، JVM اور Lua edges کے ساتھ رکھتے ہیں بغیر سب کچھ دوبارہ لکھے۔

Workstation کا موقف ہمارے Polyglot Benchmarks بلاگ اور طویل مضمون سے میل کھاتا ہے: bounded context کے لیے درست ٹول چنیں۔ لائیو ڈیش بورڈ polyglot-benchmarks.fictionally.org پر Rust (اس harness میں Actix) اکثر CPU-bound اور concurrency-sensitive HTTP قطاروں پر مضبوط دکھائی دیتا ہے — جب ADR گرم راستے پر Rust کی دلیل دے تو یہ ثبوت ہے، مذہب نہیں۔

2. Cooperative scheduling: “blocking” کا مطلب

Async Rust cooperative scheduling استعمال کرتا ہے۔ Runtime ٹاسکس کو .await پر تبدیل کرتا ہے۔ Alice Ryhl کا یادگار اصول ہر اس جگہ لاگو ہوتا ہے جہاں ہم async سروسز بھیجتے ہیں:

Async کوڈ کو کبھی بھی طویل عرصہ بغیر .await تک پہنچے نہیں گزارنا چاہیے۔

اس لغت میں “blocking the thread” صرف “IO کرنا” نہیں۔ اس کا مطلب ہے runtime کو موجودہ ٹاسک تبدیل کرنے سے روکنا۔ کلاسیکی غلطیاں:

• async fn کے اندر std::thread::sleep (کوئی await نہیں — join! کے تحت ٹائمر سلسلہ وار چلتے ہیں)۔
• Tokio worker پر بھاری لوپس، compression، crypto، vector math یا بھاری JSON۔
• async پول پر لمبے critical section کے پار sync mutex پکڑے رکھنا (مختصر لاکس ٹھیک؛ لمبے نہیں)۔

multi-threaded runtime پر آپ بگ چھپا سکتے ہیں جب تک worker threads بھر نہ جائیں۔ پروڈکشن ٹریفک آپ کے لیے اسے ڈھونڈ لے گی۔ latency SLOs کے لیے awaits کے درمیان دسیوں سے سینکڑوں مائیکرو سیکنڈز کو cooperative بجٹ سمجھیں؛ اس سے زیادہ کام async پول سے باہر رکھیں۔

3. بلاک کرنے والے کام کی تین جگہیں

جب آپ جان بوجھ کر بلاک کرنا چاہیں — مہنگا CPU یا sync IO — کام کو Tokio کے scheduler threads سے ہٹائیں۔ چیٹ شیٹ (Ryhl کے فریم کے مطابق):

طریقہ	CPU-bound	Sync IO	ہمیشہ چلتا
spawn_blocking	غیر موزوں (بڑا پول)	OK	نہیں
Rayon	OK	نہیں	نہیں
Dedicated std::thread	OK	OK	OK

3.1 sync IO کے لیے spawn_blocking

tokio::task::spawn_blocking Tokio کے blocking پول پر شیڈول کرتا ہے (ڈیفالٹ سینکڑوں threads)۔ فائل سسٹم کالز اور blocking ڈیٹا بیس ڈرائیورز کے لیے موزوں۔ مسلسل CPU کے لیے کمزور کیونکہ oversubscription OS scheduler سے لڑتا ہے — چند مختصر حساب ٹھیک، متوازی بھاری crunch کے بطور ڈیفالٹ خطرناک۔

3.2 مہنگے CPU کے لیے Rayon

Rayon CPU-bound parallelism کے سائز کا پول رکھتا ہے۔ اہم انضمام: Rayon کا انتظار کرتے ہوئے Tokio worker کو بلاک نہ کریں۔ Rayon پر spawn کریں، نتیجہ tokio::sync::oneshot سے بھیجیں، اور async طرف receiver کو .await کریں۔ Parallel iterators (par_iter) کو اب بھی بیرونی rayon::spawn چاہیے کیونکہ وہ مکمل ہونے تک بلاک کرتے ہیں۔

// Shape only — see ryhl.io for a full walkthrough
async fn parallel_work(data: Vec<i32>) -> i32 {
    let (tx, rx) = tokio::sync::oneshot::channel();
    rayon::spawn(move || {
        let sum: i32 = data.into_iter().sum(); // or par_iter inside
        let _ = tx.send(sum);
    });
    rx.await.expect("rayon task panicked")
}

کریڈٹ: یہ انضمام پیٹرن ryhl.io پر Rayon crate سیکشن کا دل ہے۔ Workstation پروڈکٹ سروسز میں وہی شکل تجویز کرتا ہے تاکہ request threads schedulable رہیں۔

3.3 ہمیشہ چلنے والے کام کے لیے dedicated threads

کبھی ختم نہ ہونے والا لوپ (dedicated DB کنکشن مالک، طویل عمر پل) کسی بھی پول سے مستقل سلاٹ نہیں کھانا چاہیے۔ std::thread::spawn ترجیح دیں اور channels سے بات کریں۔

4. مشورے کو جدید ایپ اقسام پر نقشہ

سطح	async پر رکھیں	Offload
APIs	Accept، authn، fan-out HTTP، streaming	بھاری serialization، crypto batches، scoring
Edge / gateways	Routing، cache lookup، WAF فیصلے	نایاب CPU transforms؛ ناپنے پر بہتر ہو تو Lua/njs
Agents	Tool orchestration، MCP sessions، timeouts	Embedding تیاری، eval suites، بڑے مقامی transforms
CI/CD platforms	Promote APIs، health polls، UI/API	گہری آرٹیفیکٹ تجزیہ، بلک تصدیق

Workstation مصنوعات یہ تقسیم دکھاتی ہیں: Ring Promoter کو promotion اور health gates تیز رکھنے چاہئیں؛ WSL Proxy edge راستے خالی رکھتا ہے؛ KubePilot کو بھاری تجزیے کے باوجود جواب دہ واقعہ لوپس چاہئیں۔ Rust (یا Go، یا Lua) سطح کے بعد ناپ کر چنا جاتا ہے — کبھی ہال وے بحث کے فاتح کی وجہ سے نہیں۔

5. async Rust اپنانے والی ٹیموں کے لیے آرکیٹیکچر چیک لسٹ

1. await گیپس کی فہرست: profilers اور tracing spans جو کبھی yield نہیں کرتے۔
2. blocking کام کی درجہ بندی: sync IO بمقابلہ CPU بمقابلہ forever-loop۔
3. پول چنیں: spawn_blocking، Rayon + oneshot، یا dedicated thread۔
4. حقیقی concurrency کے ساتھ لوڈ ٹیسٹ — multi-threaded runtimes N=1 پر بگ چھپاتے ہیں۔
5. فیصلہ ADR میں لکھیں؛ زبان کے انتخاب پر Polyglot Benchmarks قطاریں منسلک کریں۔
6. tail latency کے لیے shared state اور cooperative yielding پر Tokio رہنمائی دوبارہ پڑھیں۔

6. مزید مطالعہ

• Alice Ryhl — Async: What is blocking? (Rayon / spawn_blocking فریم کی بنیادی تحریک)۔
• Workstation — Polyglot Benchmarks لائیو ڈیش بورڈ۔
• Workstation — Polyglot بلاگ · Polyglot مضمون۔
• Workstation — ساتھی بلاگ اس بریف کا مختصر ورژن۔

Workstation نے شائع کیا۔ تصوراتی کریڈٹ Alice Ryhl کی عوامی تحریر کو async blocking اور Rayon پر؛ تمام پروڈکٹ فریمنگ اور polyglot رہنمائی Workstation کی ہے۔