need an event driven design...

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
earlz
Member
Member
Posts: 1546
Joined: Thu Jul 07, 2005 11:00 pm
Contact:

need an event driven design...

Post by earlz »

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
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Post by Combuster »

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)
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
earlz
Member
Member
Posts: 1546
Joined: Thu Jul 07, 2005 11:00 pm
Contact:

Post by earlz »

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...
User avatar
carbonBased
Member
Member
Posts: 382
Joined: Sat Nov 20, 2004 12:00 am
Location: Wellesley, Ontario, Canada
Contact:

Post by carbonBased »

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
earlz
Member
Member
Posts: 1546
Joined: Thu Jul 07, 2005 11:00 pm
Contact:

Post by earlz »

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
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
lode
Posts: 15
Joined: Tue Oct 17, 2006 6:28 pm
Location: Oulu, Finland

Post by lode »

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.)
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Post by Pype.Clicker »

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 :P

More on this in the wiclicker
distantvoices
Member
Member
Posts: 1600
Joined: Wed Oct 18, 2006 11:59 am
Location: Vienna/Austria
Contact:

Post by distantvoices »

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.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
User avatar
carbonBased
Member
Member
Posts: 382
Joined: Sat Nov 20, 2004 12:00 am
Location: Wellesley, Ontario, Canada
Contact:

Post by carbonBased »

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 :P
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
Post Reply