2
Ghost Что еще следует сказать некому граматею, чтобы до столь продвинутого developer-а доехало, что именно понимание того, что KoOS не является RTOS и не позволяют согласиться с коллегой "
Ты попал абсолютно по адресу.. перед тобой простая, надёжная, гибкая система, с поддержкой всего, чего тебе надо"
И ведь что удивительно, все почему-то с этим были согласны.
А не согласные - грамотеи оказываются.
Наоборот все, как мне представляется. И это у Вас проблемы с пониманием, а не у меня
А про объясняют: реальные объяснение проблем дал Serge (за что и спасибо), хоть и по второму разу
Ваши объяснения про необходимость планировщика мне совершенно понятны (с чего Вы решили обратное - не возьму в толк), но НЕ показались (пока) принципиальной проблемой.
Про XP объяснять не было необходимости - это отличие KoOS от винды и есть основная причина моей заинтересованности.
Ну не хотим, так не хотим - нет проблем.
Только способность мою понимать оставьте в покое... Если есть такая возможность. Не нуждается она ни в чьей оценке.
2
Serge Ну хорошо, давайте не будем никого ни за кого принимать
Но это же не отменяет того факта, что (назовем это так) реальной
ясности по некоторым вопросам не внесено
Как только она внесена - тут надо делать выбор: либо нечего здесь делать, либо надо начинать соответствующую работу.
1) Если коды оси могут закрыть прерывания на 5-50 секунд, это вообще-то называть не десктопом надо, а обыкновенным беспределом в кодинге.
Вопрос: эдакая бесконтрольность будет существовать всегда, или все-таки стратегией команды является постепенное внесение ясности в этот вопрос
Нет, вопрос не стоит в каких-то микросекундах, или в том что это нужно к завтра. А вот какова стратегия у команды - знать таки следует.
2) Соответственно, и при дальнейшем развитии, наверное, должен существовать же какой-то критерий по соблюдению "
определённых требований"
Будет он выполняться или нет - откуда я знаю...
Скажем, введение системы приоритетов аля в винде, уведет сегодняшние 2.56 сек в реальную бесконечность... Возможно такое или нет в последствии ???
Про общение с видео ОЗУ - был такой топик. И логичный вариант буферизации Вами (кажется) и был предложен. А вот по какому пути будет развиваться ось, извините, увидеть крайне затруднительно.
Неужели требования "отсутствия временного хвоста
не контролируемой длины" - настолько рушат всю концепцию.
Ну если рушат - так прямо и скажите: "не, не для нас это". Это же опять прямо не сказано ведь....
3) Понятно и естественно, чьих рук делом является спасение утопающих.
При этом помощь может быть оказана, а может и нет - это разные трудозатраты и эффективность как работы, так и результата (не сказано, кстати, тоже ничего)
Кроме этого, еще более интересным становится, будет ли внесено в дистрибутив нечто с "не контролируемым временным хвостом" после того, как у меня будут отлажены некие технические решения с супер-пупер-планировщиком
Честное слово, "мы не против" - не совсем тот ответ для такой ситуации
4) Не исключаю, что полной определенности со стратегией просто еще у команды нет... Так давайте продумаем какую-то ее часть - надо же когда-то этим заниматься
Никто не призывает безусловно экономить наносекунды. Призыв состоит в том, что бы не заниматься "беспределом"
В том смысле, что если закрыл прерывания, то это безобразие просто можно было именно подсчитать для конкретного компа.
Естественно, без фанатизма...
Как бы это еще понятнее........
Поймите, для разработчика системы с реальным железом, существование "
временных хвостов в бесконечность", это примерно то же самое что для Кодера:
Существует не нулевая (хотя и очень маленькая) вероятность, что "первый jmp не сработает"
Можно ли после этого написать коды, которые будут работать всегда
![Question :?:](./images/smilies/icon_question.gif)