Комментарии 26
Ужасный перевод
Будьте добры поконкретнее.
Пожалуйста:
Когда я понял, что мне нужно дополнительно учитывать ограничения реального времени, у меня родилось много инженерных решений в определённом направлении
Это что? По мне так это машинный перевод. А это:
Вооружившись этим новым пониманием, я начал замечать недостаток дисциплины реального времени в других приложениях, включая мои собственные
Это что? Нет, перевод в обоих случаях (возможно) корректный, возможно даже немного вами отредактированный, но если бы мы хотели читать машинный перевод, то пошли бы на оригинал и нажали бы кнопку translate в хроме. Можете мамой клясться, что переводили "без помощи машины", но перевод чисто механический, я с таким же успехом могу взять в руки словарь и перевести эту же статью, и у меня получится примерно то же самое, или возможно даже немного лучше, потому что у меня не стоит задачи перевести слово в слово и отработать за день, а есть задача донести мысль автора до читателя.
И это заметьте, замечание человека, для которого русский не родной язык.
ПС: хабр, почините уже этот редактор, или возьмите готовый, раз сами не умеете
Доказывать, что переводил сам не стану. Ваше замечание принял, обязательно учту. Согласен, перевод не всегда получается лаконичным и близким к русскоязычной форме. Благодарю за обратную связь. Буду признателен за неё в будущем.
ППС: хабр, почините трекер, и вообще наймите адекватных разработчиков, раз позиционируете себя как ИТ ресурс
перевод в обоих случаях (возможно) корректныйНо нет. Вас не смутило, что как это — «родилось … в определённом направлении»?
Оригинал:
Once I realized that I had to additionally take real-time constraints into account while building, it drove a lot of the engineering decisions I made in a specific direction.Тут даже машинный перевод от Deepl будет более корректен:
Как только я понял, что при создании системы необходимо дополнительно учитывать ограничения реального времени, это заставило меня направить многие инженерные решения в определенное русло.А литературно бы я это перевёл примерно так:
«Когда я понял, что при проектировании нужно учитывать ограничения реального времени, мой выбор в решении многих инженерных вопросов склонился во вполне определённую сторону»
del
Лично я поперхнулся вскоре после начала:
Вскоре после начала я столкнулся с проблемой, которая требовала обеспечить невозможность переполнения очереди событий ввода.
Канцелярит силён переводе этом в. Хотя надо отдать должное, перевод неплохо передаёт косноязычность оригинала:
Soon after I started, I ran into the issue of guaranteeing that it was impossible for the queue of input events to overflow.
Мне кажется, так было бы лучше:
Уже в начале я столкнулся с проблемой: гарантировать, что очередь событий ввода невозможно будет переполнить.
Спасибо. Но мне ваш вариант тоже как то не очень. Гарантировать, что... Не... Я бы так не написал даже просто по-русски, не в контексте перевода. В этой сфере многое диктуется схемой мышления нашей. Есть, кто очень вольно переводит, к примеру, но уходит от стилистики оригинала сильно при этом.... Стараюсь. Благодарю вас, читателей, за критику, в том числе. Подбадривает
Гарантировать, что… Не… Я бы так не написал даже просто по-русски, не в контексте перевода.Вы серьёзно? Каждое ≈пятое использование «гарантировать» в русском языке идёт со «, что».
Так тут проблема не с программами, а с текущей архитектурой ОС (ну и с подходом некоторых разработчиков)
Какая то демагогия закоренелого сишника (btw в оригинале "with an S", черт его знает что это, но вряд ли язык C) пишущего на чистом винапи, не знающего слова многопоточность и застрявшего в начале нулевых. В большинстве языков и фреймворков уже есть куча средств для того чтобы просто и быстро делать асинхронные обработчики событий пользовательского ввода. Наглухо UI повисает разве что в каких то совсем дремучих программах, ну или если какой то баг.
btw в оригинале "with an S", черт его знает что это, но вряд ли язык C
Это значит "декадЫ, не декадА".
Ну так фундаментально это действительно проблему не решает - т.к. в случае сильной нехватки физической памяти всё упрётся в pagein-pageout и никакого риалтайма не останется, сколько асинхронных обработчиков не вешай. В Linux я на это натыкаюсь с завидным постоянством.
Правда решения он никакого и не предлагает, т.к. отказ от виртальной памяти таковым быть не может
Вообще случаи сильной нехватки памяти не настолько частые чтобы тратить на их обработку большие ресурсы и усложнять дизайн приложения. Ну вот сделать чтобы выделение памяти было неблокирующей операцией в целом наверное можно, но это усложнение, тем более ведь из за всякой магии с оверкоммитом тормозить может начать уже не выделение памяти а доступ к ней, что уже вообще за гранью добра и зла чинить. И это лекарство может стать хуже болезни.
Так что в итоге факт, что приложение может тормозить при недостатке памяти просто надо принять.
Надеюсь, мне удалось убедить вас, что в основе передовых оконных приложений есть недоработки.
Никто и не спорит.
С т.з. разработки у разраба всегда дилемма: сделать доступ ресурсу синхронным или асинхронным.
Синхронный проще кодить, асинхронный удобнее пользователю, но сложнее кодить и траблшутить (troubleshooting).
В чем открытие?
Меня тянет отказаться от использования Windows, macOS и Linux в качестве основных платформ, с которыми я взаимодействую.
Ну, это смелое заявление горячих голов.
Переводить пользовательские приложения в real time interaction with user - неоправданный кусок работы. Большинство пользователей не заметят.
Честно говоря, двоякое впечатление от статьи, осталось ощущение недосказанности, была вскрыта проблема, но, а где решение или его описание? Понятно, что это перевод, но все же.
Нет никакого решения у автора: "бу-бу-бу, уйду в лес" (откажусь от Windows, MacOS, Linux). Это нытьё и демагогия.
И какая же проблема вскрыта? Что I/O вообще, и пейджинг/свопинг как частные неконтролируемые приложением случаи не очень совместимы (мягко говоря) с real-time? Так это вскрывает проблему понимания автором систем реального времени, а виртуальная память к его “проблемам” отношения вообще не имеет. А ещё он, по-моему, наивно полагает, что "попросить ОС" и "получить от ОС" — это одно и то же (это про mlock(), который в его представлении не syscall, а библиотечная функция, и я что-то не уверен, понимает ли он разницу). И у него, видите ли, есть сложности с пониманием, кто же всё-таки лочит страницы в памяти — ОС или само приложение.
После исследования его профиля позабавил, конечно, акцент на S в слове “decades” во вступлении :-) Я вот в своё время не додумался гордо называть 10+1 словом “decades”, думал (да и продолжаю думать) что это всего лишь “over decade”. Но понимаю, да, “десятки лет опыта” звучит солиднее, чем “более десяти лет опыта”.
Нууу противоречиво. Блокирующие вызовы с одной стороны блокируют поток выполнения на неопределённое время, с другой стороны - упрощают структуру кода, он остаётся линейным. С другой стороны, тому потоку, который заблокирован, точно есть что делать, если бы он не был заблокирован? И те же самые вопросы возникают, если брать оконные приложения. Автор с одной стороны ожидает, что когда он кликает, то приложение прореагирует, с другой стороны - не хочет видеть курсор ожидания. Ну дык курсор сменился на ожидание - это приложение прореагировало. Не очень хорошо, что заблокировался UI-поток, в нём происходит отрисовка. Но интерфейс приложения всё равно придётся заблокировать, каким-нибудь модальным диалогом, разве что добавив кнопку "Cancel".
Большинство gui фреймворков не имеют интеграции с async/await и т.п, а разработчики асинхронных экосистем редко думают о gui.
Я недавно экспериментировал с волокнами (fibers) на c++ и qt. Получилось довольно интересно: в потоке gui можно использовать асинхронные каналы, мьютексы, future и promise, что позволяет явно написать алгоритм вида: "заблокировать кнопку перехода на следующую страницу" - "асинхронно загрузить страницу, в процессе выполняя асинхронные сетевые запросы" - "разблокировать кнопку перехода на следующую станицу". Это действительно удобно, но есть одна проблема: при нажатии кнопки "завершить программу", она не завершается. В асинхронных экосистемах механизма отмены обычно либо нет, либо он слишком неудобен, чтобы считать асинхронный код простым. Конечно, можно найти/написать свой планировщик, более подходящий для gui, но для этого как минимум нужно знать и понимать, какие проблемы он должен решать, какие решить не может, и учитывать нюансы вроде удаления вложенных виджетов при удалении родительского в qt. Простой frontend разработчик обычно это сделать не сможет, по крайней мере так, чтобы код оставался понятным. Нужна согласованная экосистема.
Я, обычно, при нажатии "закрыть программу" скрываю программу с глаз пользователя долой и она спокойно завершается. В таком подходе только при завершении сессии могут быть проблемы, но как правило ОС успешно дожидается завершения работы процесса. Ну и стараюсь, по возможности, делать асинхронный код отменяемым.
Заголовок - "всего лишь чуть-чуть недоработанные приложения, а то был бы риалтайм"
Содержание - "ну тут в общем всю систему надо менять начиная с malloc()"
Большинство оконных приложений — это недоработанные real-time приложения