🔵 عنوان مقاله
discuss what went wrong (and right!) with implementing asynchronous I/O
🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیاده‌سازی I/O ناهمگام توضیح می‌دهد که چرا ایده «عدم انسداد» ساده به نظر می‌رسد اما در عمل با تفاوت‌های پلتفرمی و جزئیات ظریف سیستم‌عامل پیچیده می‌شود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نه‌تنها APIها متفاوت‌اند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبه‌ای یا سطحی، زمان‌بندی، و چرخه عمر descriptorها هم فرق می‌کند.
در Go، فلسفه این بوده که پیچیدگی پشت goroutine و netpoller پنهان شود تا کدنویسی ساده و «مسدودکننده» بماند، در حالی که اجرای واقعی غیرمسدودکننده باشد. این انتخاب، یادگیری و صحت را بهبود داده، اما در مقیاس بالا مشکل‌هایی مثل انسدادهای پنهان در برنامه‌ریز، نشت goroutine به‌دلیل لغو ناقص، بی‌عدالتی بین ارتباط‌ها، و اختلافات پلتفرمی در خطاها و semantics را آشکار کرده است.
اشتباهات رایج از «نشت انتزاع» می‌آیند: ساده‌سازی بیش از حد APIهای مسدودکننده، نبودِ backpressure کافی و رصدپذیری، اتکا زودهنگام به یک قابلیت خاص کرنل، و آزمون‌های ناپایدار که تفاوت‌های سیستم‌عامل‌ها را می‌پوشانند؛ خروجی آن هم تاخیرهای غیرقابل پیش‌بینی، رشد حافظه و مشکلات پایداری است.
در عوض، نقاط قوت هم پررنگ‌اند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانه‌های net/http و database/sql رفتارهای امن‌تری فراهم کرده‌اند. روی Linux، آزمایش‌های محتاطانه با io_uring امید به کاهش syscallها و بیدارباش‌ها را نشان می‌دهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارک‌های دقیق هم جلوی پسرفت‌ها را گرفته‌اند.
جمع‌بندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازه‌گیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صف‌ها، wakeupها و تعامل با scheduler سرمایه‌گذاری کنید. از قابلیت‌های جدید کرنل به‌صورت افزایشی و با احتیاط استفاده کنید و سطح برنامه‌نویسی را ساده نگه دارید. در عمل، از فراخوانی‌های مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بی‌رویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعی‌اند، اما با انضباط مهندسی به‌دست می‌آیند، نه صرفا با انتخاب یک primitive جدید.
#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller
🟣لینک مقاله:
https://postgresweekly.com/link/176360/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
discuss what went wrong (and right!) with implementing asynchronous I/O
🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیاده‌سازی I/O ناهمگام توضیح می‌دهد که چرا ایده «عدم انسداد» ساده به نظر می‌رسد اما در عمل با تفاوت‌های پلتفرمی و جزئیات ظریف سیستم‌عامل پیچیده می‌شود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نه‌تنها APIها متفاوت‌اند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبه‌ای یا سطحی، زمان‌بندی، و چرخه عمر descriptorها هم فرق می‌کند.
در Go، فلسفه این بوده که پیچیدگی پشت goroutine و netpoller پنهان شود تا کدنویسی ساده و «مسدودکننده» بماند، در حالی که اجرای واقعی غیرمسدودکننده باشد. این انتخاب، یادگیری و صحت را بهبود داده، اما در مقیاس بالا مشکل‌هایی مثل انسدادهای پنهان در برنامه‌ریز، نشت goroutine به‌دلیل لغو ناقص، بی‌عدالتی بین ارتباط‌ها، و اختلافات پلتفرمی در خطاها و semantics را آشکار کرده است.
اشتباهات رایج از «نشت انتزاع» می‌آیند: ساده‌سازی بیش از حد APIهای مسدودکننده، نبودِ backpressure کافی و رصدپذیری، اتکا زودهنگام به یک قابلیت خاص کرنل، و آزمون‌های ناپایدار که تفاوت‌های سیستم‌عامل‌ها را می‌پوشانند؛ خروجی آن هم تاخیرهای غیرقابل پیش‌بینی، رشد حافظه و مشکلات پایداری است.
در عوض، نقاط قوت هم پررنگ‌اند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانه‌های net/http و database/sql رفتارهای امن‌تری فراهم کرده‌اند. روی Linux، آزمایش‌های محتاطانه با io_uring امید به کاهش syscallها و بیدارباش‌ها را نشان می‌دهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارک‌های دقیق هم جلوی پسرفت‌ها را گرفته‌اند.
جمع‌بندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازه‌گیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صف‌ها، wakeupها و تعامل با scheduler سرمایه‌گذاری کنید. از قابلیت‌های جدید کرنل به‌صورت افزایشی و با احتیاط استفاده کنید و سطح برنامه‌نویسی را ساده نگه دارید. در عمل، از فراخوانی‌های مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بی‌رویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعی‌اند، اما با انضباط مهندسی به‌دست می‌آیند، نه صرفا با انتخاب یک primitive جدید.
#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller
🟣لینک مقاله:
https://postgresweekly.com/link/176360/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Talking Postgres with Claire Giordano
Talking Postgres with Claire Giordano | What went wrong (& what went right) with AIO with Andres Freund
Six years, a prototype, and a brief multi-layered descent into “wronger and wronger” design—what does it take to land a major architectural change in Postgres? In Episode 31 of Talking Postgres, An...