Tokio Reform is Shipped and the Road to 0.2

Bài tóm tắt Tokio 2018 2. Tăng trưởng Độ khó: Trung bình

Tokio · 2018 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài thông báo phát hành ngắn của dự án mã nguồn mở Tokio; wiki giữ phần thay đổi thiết kế và cách phát hành để ít làm vỡ hệ sinh thái.

Bối cảnh

  • Trước bản này, người dùng phải tự tạo và quản lý event loop, dù hầu hết đều làm giống nhau; chạy code trên thread của reactor khác hẳn chạy từ thread khác (thread pool). Reactor của Tokio vừa lo I/O vừa thực thi task của người dùng.

Thay đổi chính

  • Tách reactor khỏi executor: reactor chỉ lái tài nguyên I/O (TcpStream, UdpSocket), executor là phần riêng (current_thread, dự định chuyển vào crate futures). Nhờ vậy tạo kiểu mạng của Tokio từ bất kỳ thread nào, dễ viết app một hoặc nhiều thread. Thêm event loop toàn cục mặc định để đa số không phải tự dựng.
  • Phát hành ít xáo trộn: thay đổi ra dưới dạng tokio 0.1, không tăng phiên bản các crate phụ thuộc (tokio-io, futures, mio); để một thời gian dùng thử rồi mới gom mọi thay đổi phá vỡ vào một đợt (dự kiến 6–8 tuần).
  • Crate tokio thành facade: tách trait và kiểu ra nhiều crate con rồi re-export. Ứng dụng phụ thuộc tokio; thư viện chỉ chọn crate con cần dùng. Mỗi crate con ghi rõ mức ổn định: khối nền tảng giữ ổn định ít nhất một năm, crate thử nghiệm được phá vỡ nhanh hơn, nên tokio lặp nhanh mà hệ thư viện vẫn ổn định.

Vì sao

  • Gộp hai trách nhiệm (I/O và thực thi) làm mọi người dùng phải hiểu chi tiết thread; tách ra cho phép mặc định đơn giản. Hệ sinh thái thư viện phụ thuộc vào Tokio nên cách phát hành quan trọng ngang thiết kế.

Bài học cho SWE

  • Tách thành phần gộp hai trách nhiệm thường mở đường cho một mặc định hợp lý.
  • Với thư viện nền tảng: gom thay đổi phá vỡ thành đợt, khai báo mức ổn định theo từng phần, và cho ứng dụng một facade ổn định trong khi thư viện phụ thuộc phần nhỏ nhất có thể.

Liên quan