||Define the structure of an event message that will
be transferred to handlers and the type of handlers functions.
||Events processing engine must be able
- from kernel level - to 'call' a given routine running at user level. We
will assume that a given thread only has 2 stacks: the user stack
and the kernel stack. If more than 2 (out of possible 4) priviledge levels
are used in Clicker, we need the guarantee that only two can be defined for
threads that handle events.
Two options are possible:
note: to my personnal opinion, the first option is better because the second one could be fooled when the last system call was a 'wait for semaphore': running the system call to completion will then wake up the thread when any event is received.
The role of this job is to define the proper functions to be able to execute such a callback to a given address and with a given target stack context and a event to post to that handler
|end-of-event system call
||define a software interrupt that the
event handler can call to signal that it has done with events processing
and that normal operations (completion of system call and return to normal
user program) can be done - if the thread isn't in its "waiting" state -
or that the thread must be blocked again.
||decode events into handler, and defines system
calls (through the resource EVTS) to attach/detach handlers. The set of handlers
should be stored in process private datas.
||from a given event code, identify the target thread
and queue for the event, then enqueue the event and wake the thread up. This
operation should enforce a context switch if the sender of the event has