История изменений
Исправление X512, (текущая версия) :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться или ответ от клиента придёт слишком поздно? Всё повиснет? Или они всё на async IO и promise переписали? С учётом большого объёма легаси плохо в это верится.
А сколько потоков оконная подсистема Windows запускает для клиентов мы всё равно не знаем.
win32k.sys использует ядерный стек клиентских потоков вместо создания серверного потока для каждого клиентского потока.
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. Нет никаких композиторов и по 2 буфера на каждое окно, так что память экономно используется. Оригинальная система BeOS с такой же архитектурой работает даже на очень старых ПК.
В Windows GDI графика тоже сервером рисуется.
Исправление X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться или ответ от клиента придёт слишком поздно? Всё повиснет? Или они всё на async IO и promise переписали? С учётом большого объёма легаси плохо в это верится.
А сколько потоков оконная подсистема Windows запускает для клиентов мы всё равно не знаем.
win32k.sys использует ядерный стек клиентских потоков вместо создания серверного потока для каждого клиентского потока.
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. Нет никаких композиторов и по 2 буфера на каждое окно, так что память экономно используется. В Windows GDI графика тоже сервером рисуется.
Исправление X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться или ответ от клиента придёт слишком поздно? Всё повиснет? Или они всё на async IO и promise переписали? С учётом большого объёма легаси плохо в это верится.
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. Нет никаких композиторов и по 2 буфера на каждое окно, так что память экономно используется. В Windows GDI графика тоже сервером рисуется.
Исправление X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться или ответ от клиента придёт слишком поздно? Всё повиснет? Или они всё на async IO и promise переписали? С учётом большого объёма легаси плохо в это верится.
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. В Windows GDI графика тоже сервером рисуется.
Исправление X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться или ответ от клиента придёт слишком поздно? Всё повиснет? Или они всё на async IO и promise перепиали? С учётом большого объёма легаси плохо в это верится.
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. В Windows GDI графика тоже сервером рисуется.
Исправление X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться или ответ от клиента придёт слишком поздно? Всё повиснет?
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. В Windows GDI графика тоже сервером рисуется.
Исправление X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов? Что будет, если какая-нибудь команда будет долго выполняться? Всё повиснет?
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. В Windows GDI графика тоже сервером рисуется.
Исходная версия X512, :
И он вполне справляется без порождения потоков для каждого клиента.
Как он обрабатывает подключения от нескольких клиентов?
Не знаю, что там с Haiku, но сильно сомневаюсь, что рисование делается вызовами функций ОС. На трафике туда-сюда всё время потеряется.
В Haiku графика рисуется GUI сервером, клиент посылает сообщения с графическими командами. Команды группируются для эффективности и чтобы не ждать ответа. Трафик особо не тормозит. В Windows GDI графика тоже сервером рисуется.