Board.KolibriOS.org

0CodErr wrote:В svn3534 кнопка меню срабатывает только со второго раза после клика, например, по рабочему столу. И то же самое при выборе пунктов меню в приложении @menu: кликнули на пункт, появилось подменю, теперь нужно делать 2 клика для переключения на другой пункт.
В 3504 работает нормально.

Оно и до r3534 при нескольких приложениях, отжирающих процессор, так же со второго раза работало. Первый клик - активация окна и запрос на перерисовку, уничтожающую кнопки. Только раньше был второй шанс: если приложение успевало отрисовать окно до следующего запуска главного потока И пользователь не успевал отпустить кнопку мыши за это же время, то обработка нажатия кнопки мыши запускалась снова.

0CodErr wrote:После запуска refscrn иконки не перерисовываются.

Они перерисовываются, но лишь после изменения соответствующих им кусков экрана. В ревизии 3533 такого не наблюдалось. Скорее всего приложение icon тупо не отлавливает обновление экрана, когда это делается через refscrn. Возможно поломалась последовательность событий при вызове ф.15.3.

Я думаю сообщения начинающиеся с viewtopic.php?f=5&t=1602&start=835 нужно перенести в эту тему.
CleverMouse: таки да.

0CodErr wrote:Также падает при запуске GMON: page fault (kernel).

Прямая работа с портами поломалась, я её вернула в r3535.

CleverMouse

Почти Minix-совский планировщик ? Мне нравится.
Ты не против, если я увеличу кол-во очередей хотя бы до 16 и сделаю битовую маску для быстрого поиска ожидающей исполнения очереди ?

До Minix'овского его ещё пилить и пилить. В Minix очереди и приоритеты динамические, спящие потоки в очередях не участвуют и время планировщика не расходуют, за полное использование своего кванта приоритет понижается; в том, что есть, очереди по-прежнему статические, - меняющиеся только при создании и уничтожении потока - включающие в себя в том числе спящие потоки и с фиксированными приоритетами.

Я не против дальнейших изменений, конечно.

Поздравляю.

Serge, вместо битовой маски можно использовать динамический список очередей. Есть еще один нормальный вариант для небольшого числа очередей: список очередей статический; переключение выполняется только на соседнюю очередь "сверху" или "снизу"; в каждой очереди есть один служебный поток, который занимается тем, что сразу передает управление на след. поток в данной очереди или на тек. поток очереди "снизу", если он единственный в данной очереди; идентификатор такого потока в ячейке current очереди считается служебным значением, потому такая ситуация не противоречит правилу не передавать управление менее приоритетной очереди/потоку, пока есть более приоритетный.

CleverMouse, вовремя сделанное замечание. Статические кольцевые очереди - это очень плохо, тем более учитывая то, что до недавнего времени, как я понимаю, у вас такая очередь была одна. У меня все потоки, переходящие в состояние ожидания, сразу исключаются из run queue и заносятся в очереди ожидания к соотв. ресурсам. Все, что я говорил в пред. абзаце, предполагает наличие динамических очередей; упомянутые служебные потоки используются в том числе и для того, чтобы любая динамическаия очередь не опустевала полностью, даже если в ней нет ни одного рабочего потока.

Несколько ремарок по поводу того, что вы сказали в первом посте. Приоритет переднеплановых процессов/потоков должен автоматически повышаться - это почти неоспоримая истина в интерактивных системах. У меня переднеплановость связана с процессами (не с потоками). В такой ситуации нужно иметь возможность быстро повышать приоритет для всех потоков процесса. Например, можно для каждого приоритета помимо основной очереди иметь более приоритетную очередь-спутник специально для потоков переднепланового процесса. У меня сейчас переднеплановым может быть только один процесс, поэтому заполнение очередей-спутников выполняется достаточно эффективно. Еще нигде не заметил, как планируется решать основные проблемы приоритетного планирования - очень медленное продвижение или даже "замораживание" низкоприоритетных потоков при постоянном наличии работающих высокоприоритетных потоков, непрерывное ожидание высокоприоритетными потоками низкоприоритетных при постоянном наличии работающих "среднеприоритетных" потоков и т.п.

0CodErr wrote:После запуска refscrn иконки не перерисовываются.

Это опять же из-за некорректного кода GUI: В r3536 я немного поправила код GUI, проблем с refscrn и необходимостью двойного клика по кнопке меню быть больше не должно.

Phantom84 wrote:Статические кольцевые очереди - это очень плохо

На самом деле не очень плохо. Это проблема типа "планировщик отъедает 10000 тактов, хотя ему хватило бы 1000" - цифры взяты с потолка, если что, - то есть важная на стадии проектирования, важная, если в системе тысячи потоков постоянно засыпают и просыпаются, но совершенно незаметная для конечного пользователя и абсолютно незначительная на фоне текущих проблем.

Phantom84 wrote:Еще нигде не заметил, как планируется решать основные проблемы приоритетного планирования - очень медленное продвижение или даже "замораживание" низкоприоритетных потоков при постоянном наличии работающих высокоприоритетных потоков, непрерывное ожидание высокоприоритетными потоками низкоприоритетных при постоянном наличии работающих "среднеприоритетных" потоков и т.п.

Я их никак не собираюсь решать, у меня более высокоприоритетных задач по горло.

Phantom84
В наших традициях резать (или пришивать?) хвост кошке по частям. Начали с приоритетов.

CleverMouse wrote:

0CodErr wrote:После запуска refscrn иконки не перерисовываются.

Это опять же из-за некорректного кода GUI:

Code: Select all

; call change_task - because the application must have time to call f.15.8
        call    change_task

В r3536 я немного поправила код GUI, проблем с refscrn и необходимостью двойного клика по кнопке меню быть больше не должно.

Раньше (до ревизии 3534) без этого кода иконки не во всех случаях перерисовывались. Сейчас возможно и не нужно. Если не будет багрепоротов, значит все нормально.

Mario_r4 wrote:Раньше (до ревизии 3534) без этого кода иконки не во всех случаях перерисовывались. Сейчас возможно и не нужно. Если не будет багрепоротов, значит все нормально.

Решение проблем методом "а давайте попробуем немного подождать, вдруг поможет" - почти всегда плохая идея. Оно даже может работать на отдельно взятой машине, но стоит взять машину послабее и нагрузить её посильнее - рискует сломаться в неожиданных местах. Если проблема в том, что программе нужно видеть глобальную переменную в момент события, а сама глобальная переменная постоянно меняется - а так оно в данном случае и есть, - то решение должно быть "сохраним глобальную переменную в момент события где-нибудь в локальном месте, чтобы глобальная переменная могла спокойно меняться, а программа читала локальное место". r3536 - это отнюдь не только удаление вызова change_task.

http://bash.im/quote/217723 wrote:Hsilgos :Я на это втыкаю долго... И иду спрашивать, как это работает?
Hsilgos :Ведь ясно же, что это ошибка.
Hsilgos :На что мне чувак говорит : ставлю у потока более высокий приоритет и благодаря этому объект УСПЕВАЕТ вычитать содержимое переменной
Hsilgos :А ты говоришь - "Архитектура"... "Планирование"...
Hsilgos :Индийцам до нас далеко
Hsilgos :Чисто по-русски. Успеть хапнуть, пока не пришел писец...

CleverMouse wrote:r3536 - это отнюдь не только удаление вызова change_task.

Я вообще-то смотрел лог SVN если чо. Может я не настолько умен и сообразителен, но я не имбецил. Не буду спорить, что идея не самая лучшая, более того - это дрянная идея. Да и вообще 90% моего кода откровенное говно. Однако никто не делает некоторые вещи - совсем не делают. Если так раздражает я могу более вообще не трогать код ядра, так как идеи мои тоже на 90% говно. Будем честно смотреть правде в глаза. Почти 10 лет моих потуг, так и не сделали из меня хорошего программиста. Все результаты достигались тупым упорством и хождением по граблям. Потому буду делать как 99% посещающих форум - зайти и посмотреть, нет ли чего новенького, похвалить хорошистов, поругать плохишей или вообще промолчать. Потреблять в общем. Извини, что отнял твое время бессмысленным и пустым замечанием. Постараюсь далее быть чаще в read-only. Успехов!

Mario_r4, спасибо.

CleverMouse
Неясен такой момент:
- если один из пользовательских процессов уже отработал свой квант и был принудительно переключен,
- тогда будет ли включаться IDLE, или управление вернется в пользовательское кольцо?