Message Handling Model

[kenneth_phough]

I am thinking of making my operating system message-based, but I am worried that I missunderstood the term Message-based. When I became a programmer I was programing software for the infamous windows platform so I was fairly familiar with the Win32 API so when I designed my message handling model I based it off of the Win32 API getMessage(); dispatchMessage(); and CALLBACK WndProc(){} functions.
In Windows the getMessage() function gets the message and returns a 1 when successful, a 0 when WM_QUIT is sent, and -1 when unsuccessful (even though getMessage's return data type is BOOL).
The despatchMessage(); calls the WndProc() function and processes the message.

The following is my message handling model for AOS:


The kernel, when loaded, sends a message saying that it has loaded, then it goes to a while loop:

Code: Select all

while(checkMsg()!=0) {
procMsg();
}

when MSG_SHUTDOWN is sent the checkMsg() will return a 0 and the kernel will go through a shutdown process. Otherwise it will return a 1 and the procMsg() will process the message.

My questions are:
Is this a bad model for an operating system (I did model it off an API)?
My goal is to make my OS multitasking, is this model disadvantageous for multitasking?

Thanks,
Kenneth

[Legend]

If it leads to asynch I/O it doesn't seem wrong at all.

[carbonBased]

If it leads to asynch I/O it doesn't seem wrong at all.

True indeed!

Having a lot of unix/x11, and various embedded systems behind me, I prefer making use of message queues rather then registered functions. I find this more intuitive and can also double as an IPC method.

For that reason, communication with my OS will/does consist of sending messages to and from kernel message queues. Communication between threads consists of creating message queues and sending messages to each thread through these queues.

This is just an alteration on your approach... the basic idea is the same.

One crutial point, when using message queues, is using effective messages. I do not enforce a message format, but provide and use a standard format for use inside the OS. This format is similar to the one below (I can't recall it completely offhand):

Code: Select all

typedef struct _Message
{
   uint32 messageCategory;
   uint32 messageType;
   uint32 numParams;
   Pointer params[1];
} Message;

Since the message must be allocated at runtime anyway, I allocate a block large enough to contain the exact number of parameters, allowing the message to be of dynamic size with no extra overhead.

The combination of category and type should be enough for anything to accurately classify where this message came from. In other words, an app may choose to have file messages send to one queue, and window messages to another queue... however, it's possible that both get sent to one queue, of course. This is the purpose of category -- a very large scale category -- does this message concern files? memory? window system? sockets? etc.

The type then further defines the category... something such as FileTypeFileOpened, FileTypeSectionRead, FileTypeFileClosed, etc.

Just another option, if you're interested.

Cheers,
Jeff

[Daedalus]

Wow, this makes me happy too.

I designed my IPC system just like this. I hadn't read any doc's, I just wanted apps to be able to 'talk' to each other through the kernel.

Glad I got it right too!

[kenneth_phough]

Thank you very much! This helped a lot. For a long time I wasn't too certain about my messaging model and if I had the right idea but now it's all clear!

Thanks,
Kenneth