Serge wrote:А старший байт двойного слова зарезервирован для приоритета (sic!) события
Ну и ладненько. А лишний dword не сделает никакой погоды - на размере 512, kernel_alloc выделит ровно столько же памяти, 28К
Просто, если доводить это добро до ума, то надо и в sysfuncr.txt на 68:14 написать нечто, понятное программисту
А как я его напишу, если сам еще не понял до конца

Пока понял так, что первый dword, это некий код, определяющий содержание и смысл последующей информации
Ну например так:
Code: Select all
======================================================================
==================== Функция 68, подфункция 14 =======================
===== Ожидать получения сигнала, от других приложений/драйверов. =====
======================================================================
Параметры:
* eax = 68 - номер функции
* ebx = 14 - номер подфункции
* ecx = указатель на буфер для информации (28 байт)
Возвращаемое значение:
* буфер, на который указывает ecx, содержит следующую информацию:
* +0: dword: идентификатор последующих данных драйвера (-1 - при таймауте)
* +4: данные драйвера (24 байта), формат которых определяется первым dword-ом
А код, эту информацию возвращающий, мог бы выглядеть так:
Code: Select all
align 4 ;; f68:14
proc get_event_ex stdcall, p_ev:dword, timeout:dword
; ожидание любого события в очереди EventList
..............
lea esi, [eax+EVENT.code]
mov edi, [p_ev] ;copy event data
mov ecx, 7
cld
rep movsd
mov [edi-25],cl
Правильно понял

Кстати говоря, сегодня нарисована технология приема событий, как LIFO, может лучше будет FIFO (даром что-ли у нас список двунаправленный)
Следующий вопрос - магическая константа 32...
Может ну ее нафиг, вместе с полем ev_count (альтернативное определение "пустой очереди" у нас и так есть)
Пока я к такому склоняюсь...
Тем более, что такая проверка есть в send_event, но ее нет в raise_event
Если шибко мало (512) событий для 256 слотов, то можно новую релокацию делать "на ходу" (при отсутствии массива event_map - это не проблема)
Ну и наконец, самое главное, про то, что:
* Текущая реализация во время ожидания требует довольно "тяжёлых" операций переключения контекста.
Как у нас сегодня сделано:
Code: Select all
.switch:
mov eax, [TASK_BASE]
mov [eax+TASKDATA.state], byte 5
call change_task
jmp .wait
Не будет такое нормально работать: появится к примеру "флаг рисования", и будем мы сидеть в этом цикле всю жизнь.
Как я уже говорил, тут есть альтернативы....
Первая, и типовая - не ставить слот в 5-ю позицию, а просто тупо ждать, как почти везде и делается в аналогичных ситуациях.
Вторая альтернатива - открыть (сегодня закомментированную) в get_event_for_app обработку 10-бита, но добавить к этой обработке предварительную проверку TASKDATA.event_mask на этот же бит (как там везде и делается)
Тогда это могло бы выглядеть примерно так
Code: Select all
.switch:
mov eax, [TASK_BASE]
mov ebx, EVENT_EXTENDED
xchg ebx,[eax+TASKDATA.event_mask]
mov [eax+TASKDATA.state], byte 5
call change_task
xchg ebx,[eax+TASKDATA.event_mask]
jmp .wait
Такой фокус работает в get_event_ex - наличие флага, это именно наше событие, и ничье больше.
Можно и цикла не делать, как и в sys_waitforevent - это и было бы, видимо, "правильным ожиданием"
НО, в wait_event этой "правильности" уже нету - флаг могут взвести и "не наши" event-ы
Третья альтернатива - нахальная. Попытка разрешить этот вопрос для всех, и на все времена
Векторизируем то, чего у нас сегодня называется get_event_for_app. И всякий, кто поимел смелость поставить слот в 5-ю позицию, должен будет позаботиться о правильности обработчика wait_Test, который вызывается из find_next_task, ДО
довольно "тяжёлых" операций переключения контекста
Ну, скажем, примерно так:
Code: Select all
find_next_task:
.....
mov al, byte [edi+TASKDATA.state]
test al, al
jz .found
cmp al, 9
je .loop
cmp al, 5
jb .loop
jne .noevents
mov edx,SLOT_BASE
mov dh,bl
call [APPDATA.wait_Test + edx] ;это вместо call get_event_for_app
test eax, eax
jnz @f
mov ecx,[timer_ticks]
sub ecx, [APPDATA.wait_begin + edx]
cmp ecx, [APPDATA.wait_timeout + edx]
jbe .loop
@@:
mov [event_sched], eax
mov [edi+TASKDATA.state], byte 0
.noevents:
.found:
....
Это пока только набросок...
В общем, если у коллег не будет принципиальных возражений (основанных на более глубоком знании предмета), то я пока склоняюсь к "нахальным" альтернативам

Но предупредить-то я должен был
