Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Jul 23, 2019 1:07 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 22 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Mon May 27, 2013 3:35 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
0CodErr wrote:
В svn3534 кнопка меню срабатывает только со второго раза после клика, например, по рабочему столу. И то же самое при выборе пунктов меню в приложении @menu: кликнули на пункт, появилось подменю, теперь нужно делать 2 клика для переключения на другой пункт.
В 3504 работает нормально.

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

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon May 27, 2013 3:59 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
0CodErr wrote:
После запуска refscrn иконки не перерисовываются.

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Mon May 27, 2013 4:01 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Я думаю сообщения начинающиеся с viewtopic.php?f=5&t=1602&start=835 нужно перенести в эту тему.
CleverMouse: таки да.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Mon May 27, 2013 4:10 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
0CodErr wrote:
Также падает при запуске GMON: page fault (kernel).

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

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon May 27, 2013 4:30 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
CleverMouse

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


Top
   
PostPosted: Mon May 27, 2013 4:55 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
До Minix'овского его ещё пилить и пилить. В Minix очереди и приоритеты динамические, спящие потоки в очередях не участвуют и время планировщика не расходуют, за полное использование своего кванта приоритет понижается; в том, что есть, очереди по-прежнему статические, - меняющиеся только при создании и уничтожении потока - включающие в себя в том числе спящие потоки и с фиксированными приоритетами.

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

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon May 27, 2013 6:11 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Поздравляю.

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

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

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


Top
   
PostPosted: Mon May 27, 2013 7:51 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
0CodErr wrote:
После запуска refscrn иконки не перерисовываются.

Это опять же из-за некорректного кода GUI:
Code:
; call change_task - because the application must have time to call f.15.8
        call    change_task

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

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon May 27, 2013 7:55 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
Phantom84 wrote:
Статические кольцевые очереди - это очень плохо

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

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

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon May 27, 2013 8:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Phantom84
В наших традициях резать (или пришивать?) хвост кошке по частям. Начали с приоритетов.


Top
   
PostPosted: Mon May 27, 2013 8:10 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
CleverMouse wrote:
0CodErr wrote:
После запуска refscrn иконки не перерисовываются.

Это опять же из-за некорректного кода GUI:
Code:
; call change_task - because the application must have time to call f.15.8
        call    change_task

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

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Mon May 27, 2013 8:24 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
Mario_r4 wrote:
Раньше (до ревизии 3534) без этого кода иконки не во всех случаях перерисовывались. Сейчас возможно и не нужно. Если не будет багрепоротов, значит все нормально.

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

_________________
Сделаем мир лучше!


Top
   
PostPosted: Mon May 27, 2013 9:00 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
CleverMouse wrote:
r3536 - это отнюдь не только удаление вызова change_task.

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Mon May 27, 2013 9:06 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
Mario_r4, спасибо.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Wed May 29, 2013 2:57 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
CleverMouse
Неясен такой момент:
- если один из пользовательских процессов уже отработал свой квант и был принудительно переключен,
- тогда будет ли включаться IDLE, или управление вернется в пользовательское кольцо?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 22 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited