Я дивився цю розмову про впровадження Async IO в Rust, а Карл згадує про дві потенційні моделі. Готовність та завершення.
Модель готовності:
- ви скажете ядро, яке ви хочете прочитати з сокета
- робити інші речі на деякий час ...
- ядро повідомляє вам, коли сокет готовий
- ви читаєте (заповнюйте буфер)
- робіть все, що вам потрібно
- звільніть буфер (відбувається автоматично з Rust)
Модель завершення:
- Ви виділяєте буфер для ядра для заповнення
- робити інші речі на деякий час ...
- ядро повідомляє вам, коли буфер був заповнений
- робити все, що вам потрібно, з даними
- звільнити буфер
На прикладі Карла, використовуючи модель готовності, ви можете переглядати заповнення готових сокетів і звільняти глобальний буфер, завдяки чому здається, що він буде використовувати набагато менше пам'яті.
Тепер мої припущення:
Під кришкою (у просторі ядра), коли сокет вважається "готовим", дані вже є. Він потрапив у сокет через мережу (або з будь-якого місця), і ОС тримає дані.
Це не так, якби магічне розподілення пам'яті не відбувається в моделі готовності. Просто ОС це абстрагує це від вас. У моделі завершення ОС вимагає виділити пам'ять до того, як дані дійсно надходять, і очевидно, що відбувається.
Ось моя змінена версія моделі готовності:
- ви скажете ядро, яке ви хочете прочитати з сокета
- робити інші речі на деякий час ...
- ЗМІНА: дані надходять в ОС (деяке місце в пам'яті ядра)
- ядро повідомляє вам, що сокет готовий
- ви читаєте (заповніть інший буфер окремо від буфера ядра abover (або ви отримаєте вказівник на нього?))
- робіть все, що вам потрібно
- звільніть буфер (відбувається автоматично з Rust)
/ Мої припущення
Мені подобається, щоб програма для простору користувачів була невеликою, але я просто хотів трохи уточнити, що насправді відбувається тут. Я не бачу, щоб одна модель по суті використовувала менше пам'яті або підтримувала більш високий рівень одночасного вводу-виводу. Я хотів би почути думки та глибші пояснення цього.