Zig – Bổ sung triển khai std.Io cho io_uring và Grand Central Dispatch

 (ziglang.org)
2 điểm bởi GN⁺ 2026-02-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Mô-đun std.Io.Evented của thư viện chuẩn Zig nay đã được tích hợp thêm triển khai dựa trên io_uring và Grand Central Dispatch (GCD)
  • Cả hai triển khai đều hoạt động theo cách chuyển đổi stack ở không gian người dùng (fibers, stackful coroutines, green threads)
  • Hiện vẫn đang ở giai đoạn thử nghiệm, và cần thêm các công việc tiếp theo như cải thiện xử lý lỗi, loại bỏ logging, phân tích nguyên nhân suy giảm hiệu năng, và tăng cường kiểm thử
  • Trong cùng một mã ứng dụng, có thể chỉ thay backend I/O để dễ dàng chuyển giữa io_uring và GCD
  • Hai triển khai cũng hoạt động trong chính trình biên dịch Zig, và sau khi được ổn định hóa trong tương lai, chúng có thể phát triển thành nền tảng tích hợp I/O bất đồng bộ theo từng nền tảng

Triển khai std.Io.Evented dựa trên io_uring và GCD

  • Vào cuối chu kỳ phát hành Zig 0.16.0, std.Io.Evented đã được cập nhật để phản ánh các thay đổi API mới nhất

    • Các triển khai mới được bổ sung là io_uring (Linux) và Grand Central Dispatch (GCD) (macOS)
    • Cả hai đều sử dụng kỹ thuật chuyển đổi stack ở không gian người dùng (fibers, stackful coroutines, green threads)

  • Hai triển khai hiện đang ở trạng thái thử nghiệm, và vẫn còn nhiều hạng mục cần cải thiện để có thể sử dụng ổn định

    • Cần cải thiện xử lý lỗi
    • Cần loại bỏ logging và chẩn đoán nguyên nhân suy giảm hiệu năng (hiệu năng của trình biên dịch bị giảm khi dùng IoMode.evented)
    • Vẫn còn một số hàm chưa được triển khai và cần mở rộng độ bao phủ kiểm thử
    • Cần bổ sung hàm dựng sẵn để kiểm tra kích thước stack tối đa theo từng hàm (nhằm đảm bảo tính thực tiễn khi overcommit bị vô hiệu hóa)

Ví dụ thay thế triển khai I/O

  • Trong cùng một mã ứng dụng, có thể hoạt động chỉ bằng cách thay backend I/O

    • Trong mã ví dụ, nếu dùng std.Io.Evented thay cho std.Io.Threaded thì chương trình sẽ chạy trên nền io_uring
    • Hàm app vẫn giữ nguyên, và kết quả đầu ra (Hello, World!) cũng giống nhau

  • Có thể xác nhận khác biệt giữa hai cách chạy qua so sánh kết quả strace

    • hello_threaded là lời gọi I/O dựa trên luồng thông thường
    • hello_evented sử dụng các system call của io_uring (io_uring_setup, io_uring_enter, v.v.)

Áp dụng vào trình biên dịch Zig và tình hình hiện tại

  • Bản thân trình biên dịch Zig cũng hoạt động bình thường khi dùng std.Io.Evented

    • Có thể chạy trình biên dịch trên cả io_uring và GCD
    • Tuy nhiên, nguyên nhân suy giảm hiệu năng vẫn chưa được xác định, nên cần phân tích thêm

  • Thay đổi này đưa mã Zig tiến gần hơn đến một cấu trúc có thể dễ dàng hoán đổi triển khai I/O

    • Đặt nền móng để xử lý một cách thống nhất các mô hình I/O bất đồng bộ theo từng nền tảng

Các việc cần làm tiếp theo

  • Cần cải thiện hiệu năng và tăng cường kiểm thử để có thể sử dụng ổn định
  • Nếu bổ sung tính năng quản lý kích thước stack, việc sử dụng thực tế sẽ khả thi hơn cả trong môi trường tắt overcommit
  • Khi hoàn thiện, lớp trừu tượng hóa I/O bất đồng bộ của Zig được kỳ vọng sẽ mạnh hơn đáng kể

Kết luận

  • Bản cập nhật lần này là một bước tiến quan trọng trong việc mở rộng hệ thống I/O chuẩn của Zig
  • Việc tích hợp io_uring và GCD đặt nền móng để đảm bảo tính nhất quán của xử lý bất đồng bộ giữa các nền tảng
  • Khi công việc ổn định hóa hoàn tất trong tương lai, khả năng hiện thực hóa mô hình I/O hiệu năng cao và linh hoạt của Zig sẽ được mở rộng

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-15
Ý kiến trên Hacker News

  • Tôi không hẳn là fan của Zig, nhưng thật vui khi thấy một nhóm nhỏ vẫn đều đặn tiến bộ
    Thái độ coi trọng thử nghiệm và cải thiện dần dần hơn là cố hoàn thiện ngay từ đầu rất đáng ấn tượng
    Tôi nghĩ việc hướng tới mục tiêu dài hạn quan trọng hơn là vội vàng phát hành 1.0
    Đây là thành tựu đáng kinh ngạc đối với một dự án xoay quanh một người làm trung tâm, và những người nỗ lực xứng đáng được công nhận

    • Mỗi khi học một ngôn ngữ mới, tôi thường thử làm một game engine có máy chủ multiplayer TCP/UDP, và gần đây tôi đã thử với Zig
      Đây là trải nghiệm thú vị và hiệu quả nhất từ trước đến nay
      Sự đơn giản của Zig hợp với tôi hơn nhiều so với cách quản lý bộ nhớ quá nghiêm ngặt của Rust
      Đời ngắn lắm, tôi chỉ muốn viết phần mềm nhanh và gọn gàng

  • Mỗi bài viết về Zig đều có nhiều lời chỉ trích, nhưng tôi không hiểu sao mọi người lại bận tâm đến vậy
    Tinh thần kỹ sư của Andrew và đội ngũ trong việc hiện thực hóa điều họ tin tưởng lại khiến tôi thấy được truyền cảm hứng
    Không cần lo Zig có trở thành xu hướng chính hay không, chỉ cần nó giúp giải quyết vấn đề là đủ
    Không cần coi ngôn ngữ như một phần bản sắc của mình

    • Muốn giảm hiện tượng này thì phải thay đổi động lực kinh tế mà lập trình viên nhận được
      Ngôn ngữ và thư viện rốt cuộc là “kỹ năng có thể bán được”, nên mọi người luôn để ý đến tính thương mại của công cụ mình dùng
      Ngoài ra, xu hướng những người ra quyết định xem kỹ sư như tài sản có thể thay thế cũng là một vấn đề
    • Kiểu tranh cãi ngôn ngữ này không phải chuyện riêng của Zig
      Nó đã lặp lại với Lisp, Ruby, Rust và nhiều ngôn ngữ khác, và cuộc chiến bản sắc là một căn bệnh mãn tính của ngành
    • Một stack ngôn ngữ mới sẽ làm tăng gánh nặng bảo trì trong các bản phân phối Linux
      Dù cần quản lý dài hạn về bảo mật, hỗ trợ kiến trúc và nhiều thứ khác, các nhà phát triển thường bỏ qua chi phí đó
      Zig vẫn chưa ổn định nên gói chỉ biên dịch được ở một số phiên bản nhất định
      Cũng có thể nghi ngờ liệu có cần giải quyết bằng ngôn ngữ mới những vấn đề vốn có thể xử lý bằng cách cải thiện ngôn ngữ khác hay không
    • Muốn trở thành ngôn ngữ chủ đạo thì cần một hệ sinh thái thư viện có thể dự đoán được bao phủ phần lớn các trường hợp sử dụng

  • Tôi cảm thấy theo dõi Zig trước khi nó đạt 1.0 thì cũng không có nhiều ý nghĩa
    Cấu trúc hiện tại rất có thể sẽ còn bị viết lại nhiều lần
    Tôi từng quan tâm, nhưng không biết liệu mình có được thấy 1.0 trong đời này không

    • Trên thực tế, phần lớn thay đổi phá vỡ tương thích của Zig xảy ra ở thư viện chuẩn (stdlib)
      Những chức năng cơ bản như I/O file gần như vẫn giữ nguyên, chỉ thay đổi namespace
      Tôi nghĩ một “ngôn ngữ đang sống” vẫn tốt hơn
      Sẽ hay hơn nếu sau 1.x có chiến lược quản lý giao diện theo phiên bản để giữ stdlib gọn nhẹ
    • Tôi thích bản thân ngôn ngữ Zig, nhưng bắt đầu nghi ngờ chất lượng stdlib
      Khi tự xây dựng framework I/O, tôi đã phát hiện thiếu test và cả mã assembly sai
      Tôi đã chỉ ra nhiều lần nhưng không được sửa, nên mức độ tin cậy giảm đi
    • Có thể còn do dự với các dự án lớn, nhưng Zig đã có giá trị kinh doanh
      Đặc biệt trong môi trường cloud, tối ưu hiệu năng có thể giúp giảm hơn 90% chi phí máy chủ
      Với Python hay Node sẽ có giới hạn, nên cuối cùng cũng phải đi xuống một trong C, C++, Rust hoặc Zig
      Trong số đó, Zig dễ học hơn, cũng dễ đọc và dễ test hơn
    • Tham khảo thêm, Bun cũng được viết bằng Zig
      Đây đã là ngôn ngữ được dùng ở cấp độ thực tế
    • Nhóm của chúng tôi (ZML) đã liên tục bám theo nhánh master của Zig kể từ khi std.Io được đưa vào
      Phần lớn các thay đổi thực sự mang lại cảm giác là cải tiến ngôn ngữ

  • Thật thú vị khi Zig thử triển khai io_uring trước trong lúc hỗ trợ io_uring của Rust vẫn chưa hoàn thiện
    Trong Rust, việc thiết kế các abstraction vừa an toàn vừa zero-cost là rất khó

  • Tin này thực ra vẫn nói về một triển khai chưa hoàn chỉnh
    Ví dụ, phiên bản GCD chưa có networking
    Giao diện đang ngày càng lớn hơn nên giống một snapshot hiện tại hơn là thứ đã hoàn thiện

    • Nhưng ngay phần mở đầu bài viết đã nêu rõ đây là giai đoạn thử nghiệm,
      và còn liệt kê cụ thể 6 đầu việc lớn cần làm tiếp theo

  • Có một issue liên quan đến tối ưu bộ nhớ stack
    Cần có khả năng để dù dùng [500]u8 ở các block khác nhau thì stack frame cũng chỉ chiếm 500 byte
    Điều này đặc biệt quan trọng với stack coroutine của green thread

  • Tôi đánh giá tích cực những nỗ lực cải tiến liên tục của Zig
    Hiện tại chưa có ngôn ngữ nào xử lý io_uring thật sự tốt
    Nếu Zig giải quyết tốt phần này thì sẽ có lợi thế lớn
    Tôi nghĩ thái độ coi trọng học hỏi và thử nghiệm đáng giá hơn sự ổn định

    • Thật thú vị khi người ta còn muốn async ngay cả ở ngôn ngữ cấp thấp
      Trong Zig, tôi thích dùng libxev để điều khiển io_uring trực tiếp hơn
    • Tôi cũng tích cực, nhưng vẫn tò mò khi nào Zig sẽ phát hành phiên bản ổn định dài hạn (LTS) như C
      Yếu tố thành công của C là sự ổn định và văn hóa phát triển nhất quán

  • Tôi thích việc Zig nghiêm túc với mục tiêu freestanding
    Tôi kỳ vọng ở phiên bản 0.16 khả năng tái sử dụng mã sẽ cao hơn

  • Lâu rồi tôi mới nhìn lại bên trong macOS, và thật vui khi thấy GCD vẫn được duy trì
    Tôi cho rằng đây là một cách tiếp cận cân bằng với lập trình song song

  • Trong khi các ngôn ngữ khác chỉ tranh cãi, Zig thì tự mình thử làm và nếu cần thì rollback
    Tôi tin rằng API đã được kiểm chứng trong thực tế mới là thiết kế tốt nhất
    Có thể giữ lại phiên bản cũ, hoặc lên bản mới để có công cụ sạch hơn và nhanh hơn

    • Jai tập trung vào phát triển game nên thiếu tính phổ dụng và độ an toàn
      Nó phức tạp như C++, trong khi Zig vẫn giữ được sự đơn giản ở mức C
      Carbon thì vẫn còn chưa thành hình
    • Chỉ trích Zig vì chưa phải 1.0 thì khá kỳ lạ
      Jai đã ở closed beta suốt 11 năm, còn Zig đã được dùng trong nhiều dự án thực tế
    • Tôi nghĩ một ngôn ngữ dù mất 20 năm nhưng được hoàn thiện đúng cách vẫn tốt hơn
      Những thay đổi thiếu kiểm soát từng thấy ở Python 2→3, Rust async, Go generics, C++... mới thật sự có hại