OSDev.org

I am wanting for my OS(and its apps) to be completely event driven... but I can not get down a half-decent design
at one end I let the OS do all the work by providing little "event stacks" but the problem with them is 2 drivers might get conflicted and try to share the same event number(even something as easy as trying to have 2 consoles in 1 thread)
and then theirs the other end where I let the app or driver do all the work.. like have to keep up with different event stacks for each process and such which just is proving very retarded at coding... seems like you do things over and over

but I can really not think of a way to have a design in the middle of the 2... I just can't think of a way without running into even more problems

btw by event stack I mean an array of function pointers that are the event handlers

but the problem with them is 2 drivers might get conflicted and try to share the same event number

Maybe you should have your kernel manage event numbers, rather than having applications/drivers choose them.

If you want a cheap algorithm for this, pick the top 22 bits from the tasks cr3 that generates the event, and have the generating app pick the bottom 10 bits manually (which allows for 1024 different events a task)

hmmm an intresting point... I don't have CR3 stuff yet(barely multitasking actually) but instead I'll use address of their thread struct
so basically would give any thread up to 1024 events... also I'm going to have to make a linked list form... my current version is just a flat array(with the numbers being element number in array)

thanks...

What's wrong with a basic message queue system?

You allocate messages, and send them into a queue. The resultant application then reads from the queue. This is simple, generic, and works.

Perhaps I'm misinterpretting your issues, though.

--Jeff

so you mean make it message driven?
if so then it would defeat what I think my OS will be cool for.. in my OS you won't have to periodicalyl run a message checker function, you just wait for it to happen.... much easier to me... but of course windows mesaging system really made me look down on it anyway

Hi,

hckr83 wrote:so you mean make it message driven?
if so then it would defeat what I think my OS will be cool for.. in my OS you won't have to periodicalyl run a message checker function, you just wait for it to happen.... much easier to me... but of course windows mesaging system really made me look down on it anyway

If events are delivered via. some sort of callback without the receiver knowing when they will arrive, then you'll have re-entrancy problems and each application will probably implement it's own internal buffering to avoid those re-entrancy problems. It will be like signal handlers in POSIX/Unix (or even IRQ handlers), where you need to be extrememly careful what you do inside an "event handler".

For Windows (IMHO) the big problem is that messages are a fixed size, and too small (a pair of 32 bit values only) . For example something simple like sending a file name becomes a pain in the neck (IIRC there's a function to convert it into a unique identifier so it can be sent, and another function to convert it back into a string).

There are lots of different ways messaging can be implemented though - synchronous or asynchronous, with fixed sized messages or with variable sized messages, different security rules (who can send what to who), different effects on scheduling, etc.


Cheers,

Brendan

I started by an event based system. Then I ran to re-entrancy problems, so now I'm taking a middle road: IPC is message based, but the application can elect to receive a signal when new messages arrive into the queue. (and fake being entirely event based.)

in my experience, the process of resolving a event identifier into a handler descriptor in a way such that you have enough flexibility to temporarily "block" events that shouldn't occur while a given processing is performed is overcomplicated to be handled properly within the kernel.

My preferred way now is to have sorts of message queues and to allow for one thread to "listen" on several queues at the same time.

Not mentionning the fact that general programming in a pure event-driven model can quickly become a nightmare when the application gets a bit more complex. Try to implement a HTTP proxy in a single process using only "select" and non-blocking IO to support multiple clients/servers at a time and you'll see what i mean

More on this in the wiclicker

I'd use messages for the ipc (also for delivery of events.) You can say: I want a message from X, so no one else disturbs you except of the event-deliverer.

in BlueIllusionOS (sorry for the merchandising) events are delivered as sort of primitive, fixed size messages on an extra path (there's a message queue and a event queue per process - the difference is, that events are non-blocking au contraire to messages - they just happen).

To assign so called "handlers" which are invoked by the kernel upon delivery of an event are something bad, honestly. Imagine you've got a process waiting on semaphore - oh horror, state saving & restoring after having called the event handler ... and what if the event handler touches stuff which is protected by the semaphor on purpose? I do not want to imagine this, but believe me, this bears evil stuff and roots of any kind of krank errors.

fazit: stay with messaging and build event stuff around message queues. It's safe.

BTW: consider your kernel an event based system: if you press a key, that's an event - i your harddrive has read/written a block - that's an event too (hardware interrupt) - if your software issues a system call, you can consider this an event too.

Pype.Clicker wrote: Try to implement a HTTP proxy in a single process using only "select" and non-blocking IO to support multiple clients/servers at a time and you'll see what i mean

And how Been there, done that... how I make a living

I've worked on systems based on VxWorks whereby each kernel module has its own message queue. Applications query each module through a known public interface in order to acquire that module's message queue. They then send requests to the modules through it's queue, and specify a queue pointer to store the result in.

In my opinion, this works fairly well. The application can chose to have a different queue per each request, if it wishes -- a different queue per kernel module, or the same queue for everything (which can exist in one thread, of course, limiting re-entrancy problems).

Another issue with callbacks is privilege level -- a P0 kernel calling into a P3 app can be complicated. Copying a message is (relatively) simple (especially with shared memory).

--Jeff