Which do you like better, Event based, or message

[earlz]

Hi I'm trying to decide if I should implement an alternative message based system(I am doing event anyway)

now then
Event based systems are like VB, they call a function when something happens, and message based is like normal Windows programming(in say C) in which you have a message stack thingy and when something happens it gets added to the stack


btw, for option 3 could you please tell me what that system is

[Kemp]

I suspect that your "event based" model merely has the message checking loop hidden from the programmer by whatever generates the code. For instance, Delphi provides the user with this model, but behind the scenes it is all message based and the functions are simply called based on the incoming messages.

[earlz]

no,no
this will not be message based AT ALL

it performs at a lower level than windows though
like ok when you type something it calls irq1 and then irq1 fires the appropriate event handler function

[Kemp]

In response to the original question, I personally prefer the message based model. This is because using things such as interrupts as a routine thing doesn't quite seem right to me, and messages seem a lot "cleaner" and nicer. It's entirely a matter of opinion though, so in the end you should use whichever seems best for you. If you decide you prefer the other method after all then you can always go back and rewrite everything ;D

[earlz]

Well I think I got a way to do messaging with just minor changes
my event handler caller will check to see if the function pointer is 0 and if so then it will call event 0 function which is the "default" event and so if you just have the default event put the event number and parameters on a stack or queqe or whatever then that should work(kindof)

[Combuster]

well, both systems have obvious advantages and disadvantages.

first of all, vb is based on windows so it IS message based at the core. However, vb builds wndproc stubs in the forms which call events. For the rest its a message polling loop while the application is not doing anything (or you're issuing DoEvents), so even vb is not truly event based, although it does a good job at imitating it

well, for event based
Events can be called at any time, independent on wether we are busy or not, so if the user wants something, we can satisfy the users demands and continue with the more demanding work for high response times. in message systems you'll have to call message polling functions at regular intervals which can slow things down. (Polling is considered slower than interrupts in general)
The other (which i haven't read) advantage is that for an event based modelling, you dont need to queue actions (wether it be events or messages) to be read later, you just dispatch an event when it needs to and save the memory for later.
The downside, your app must be fully armed against multithreadedness or in any and all other ways the os likes to get into race conditions and the like, which implies the need of synchronisation, which can reduce the speed advantage

for messaging systems (and vb/delphi/whatever event-a-likes), the advantages and disadvantages reverse, where imho event-a-likes just make it look better.

On another note, if you have event delivery, nobody stops you from queueing events locally for a homebrew message handler without further kernel intervention.

That said, the choice is more or less a matter of taste.

Which brings me to the point, I wouldnt mind using both at the same time, using whichever method brings the best advantages at the time, but i do have a small preference for event-driven applications (mainly because i hate the 8-screens-big switch statements).

My OS in design however changes roles, it appears close to a message passing system (subjective statement), while it effectively does event delivery.

[earlz]

yea, I'll probably have API support for turning the event system into a message based system

but yea, I HATE C/C++ programming for windows because of how much I hate the message system

another thing, my design for my OS is single-tasking


the big design problem I have right now is what if an event happens while an event is running

I though about using a stack but I can't figure out how to code it

edit:
IMO the really good thing about my OS is I have some prebuilt event handlers(they will handle all the libc and api stuff) so say ummm if you needed to do stuff like in a paint program, having hotkeys but also drawing wiht the mouse you could just change the keyboard handler but call the standard keyboard handler and then use getc(or whatever) and act on that

[Pype.Clicker]

wiclicker: EventsApi

Initially, i had planned to have an event processing engine in Clicker. The goal of the engine was to allow each process to register handlers that would apply when a given event is delivered to the process. The handler does not only define the code to be invoked, but also who is entitled to send it (by means of process groups), what priority it has (e.g. only a higher priority event can interrupt a lower-priority event) and so on.

wiclicker: Why we need Ports for Events

Now, with experience, it appeared that it was not such a good idea to have a "here's a function to be invoked on event XXX" in a kernel. First because it means that even if you just want to wait for a timeout, you need to register a new handler, activate it, etc. Events are fine when you are in an event-oriented system (such as handling a GUI), but for the rest, they can quickly become a pain.

For instance, it's especially tricky to allow an "event" to resume a computation ... you need to introduce an extra semaphore and define a handler that will "signal" it while your main code had "wait" on the semaphore just after the handler had been installed. And if you want to wait not for one such events but instead for one-out-of-many-possible-events, and prevent all the other to occur once the first one has been received, you're pretty much entering nightmare-land.

I HATE C/C++ programming for windows because of how much I hate the message system

Not all message-to-event translators are ugly as a large switch. you may very well have a library with "register_event(XXX, f())" and "messages_to_events(message_queue)".

[distantvoices]

@jordan3: to hate something is no way to learn.

take it as it is and don't block yourself from doing what has to be done just because you hate. that's nonproductive.

I go for messages. sooner or later I'm gonna do them via ports, as my studies permit. Summer holydays are fine and they are first and foremost dedicated to spending lootsatime with my fairy.

Oh and btw: whether it's message or event is merely definition. In OS realm, everything is an event, be it a hardware irq, be it a kernel call from a user application. Just keep this in mind. What you do with it is the crispy and thrilling stuff.

Ah ... Von Neumann has definitely invented something cool ...

[ot]
well ... as the heat increases here my hankering to type converges absolutely to zero, eh? Nonasymptotic, so to say. Not really a stability point in the sense of Ljapunov. *fg*
[/ot]

[Candy]

but yea, I HATE C/C++ programming for windows because of how much I hate the message system

I just spent four hours looking through a program that causes a null pointer exception in DispatchMessage. It gives me no clues whatsoever about what it's doing or anything.