سلام دوستان،
دوباره کوستاس از تیم اصلی با قسمت دوم سری WebAssembly من است. برای خلاصه‌ای سریع از مقاله هفته گذشته، گلوگاه‌های کار با چندین کتابخانه مشتری و ایده جدید تدوین را مورد بحث قرار دادم. mgclient به یک ماژول WASM، به طور موثری وابستگی بین عملیاتی به اتصالات را کاهش می دهد. امروز، با بحث در مورد چند ایده کلیدی در پشت WASM و اکوسیستم آن عمیق‌تر به دنیای WebAssembly خواهم رفت و با یک سوال شروع می‌کنم: چگونه یک کتابخانه C را در یک ماژول WASM کامپایل کنیم؟
برای انجام این کار، ما به یک کامپایلر نیاز داریم و Emscripten SDK یک زنجیره ابزار کامپایلر است (بر اساس LLVM) که یک برنامه C را به یک ماژول WASM کامپایل می کند که می تواند از مرورگر یا هر موتوری که جاوا اسکریپت را اجرا می کند (مانند node، V8 و غیره) مصرف شود. .). این یک سوال کلیدی ایجاد می کند: برای کتابخانه های سیستمی مانند POSIX چه اتفاقی می افتد؟ به هر حال، مرورگر یک محیط محدود است و دسترسی آن به رابط های سطح پایین سیستم مانند IO، threading و غیره محدود است. علاوه بر این، POSIX مستقل از پلتفرم نیست، بنابراین با ارزش اصلی WASM، که واقعاً مستقل از پلتفرم است، در تضاد است. پاسخ کلیدی به این سوال این است که کتابخانه های سیستم شبیه سازی شده اند. Emscripten نه تنها یک فایل ماژول WASM بلکه یک فایل جاوا اسکریپت تولید می کند که رفتار فراخوانی های سیستم را شبیه سازی می کند.
قابل توجه، از آنجایی که کامپایلر Emscripten یک فایل جاوا اسکریپت را نیز تولید می کند، در نتیجه مصرف کننده ماژول به محدودیت های JS محدود می شود. این ممکن است به خوبی با مرورگر کار کند، اما مثلاً Ruby یا Rust نمی تواند کار کند. تکیه بر کتابخانه های سیستمی که به عنوان جاوا اسکریپت صادر می شوند پاشنه آشیل WebAssembly است زیرا به طور ضمنی الزامات اجرای JS را تحمیل می کند. خوشبختانه، جامعه ضرورت انتقال WebAssembly را فراتر از لبه های مرورگر تشخیص داده و WASI (واسط سیستم WebAssembly) را ارائه کرده است. به زبان ساده، WASI یک جعبه ماسه‌بازی کامل برای ویژگی‌های مشابه سیستم فراهم می‌کند. این بسته بر روی یک SDK کامل است که قادر به تولید یک فایل WASM مستقل است که می تواند توسط هر زمان اجرا منطبق با WASI مصرف شود، بنابراین یک ویژگی واقعی و یکپارچه مانند بین عملیات را در هر محیط اجرایی ارائه می دهد. علاوه بر این، WASI یک زمان اجرا برای خود فراهم می‌کند که می‌تواند فایل‌های WASM مستقل را با ماژول WASM اجرا کند.
نکته جالب این است که Emscripten از فرمی از کامپایل مستقل برای WASM نیز پشتیبانی می کند. یعنی هر کد چسب جاوا اسکریپت کتابخانه سیستمی را حذف می‌کند و در عوض از WASI استفاده می‌کند (آره، این بسیار مبهم نوشته شده است زیرا اسناد موجود در Emscripten خود در این مورد خیلی واضح نیستند). با این حال، پشتیبانی WASI آنها محدود است، و من با WASI SDK برای ماژول های مستقل واقعی WASM استفاده می کنم. دو سنت من در مورد Emscripten این است که ممکن است در آینده به طور کامل از WASI پشتیبانی کند، حتی اگر کاملاً مستقل باشد. از این گذشته، از قبل زیرمجموعه ای از آن را پشتیبانی می کند، پس چرا به طور کامل مطابق با WASI نباشید؟
و حالا برای گیلاس در بالا و عنصر گم شده ذکر شده در مقاله قبلی – wasmer. این یک زمان اجرا WASM است که از WASI پشتیبانی می کند و به عنوان یک کتابخانه در بسیاری از زبان ها (جاوا، go، PHP، Ruby و غیره) در دسترس است. با wasmerما می‌توانیم در تئوری، تمام فناوری‌های اتصال (JNI و غیره) را با یک زمان اجرا که همان معنای جهانی را دارد جایگزین کنیم. تنها چیزی که برای هر زبان پشتیبانی شده اندکی تغییر می کند API است (برای انطباق با پارادایم هر زبان).
با تمام اطلاعات WebAssembly که در این مقاله مرور کردیم، پایه محکمی برای بحث در نهایت ایجاد کردیم jsmgclient، اولین آداپتور مشتری مبتنی بر WASM Memgraph. Buuuuut، برای آن، شما باید قسمت آخر مجموعه را بخوانید.
صلح!
