OSDev.org

I've implemented my IPC system of my kernel with GetMessage, SendMessage, PostMessage, ReplyMessage
Only PostMessage is asynchronous, so i need to store it temporarily.
My problem is that i create buffer in kernel to store the posted message, i may run out of kernel memory.
Eg. In my kernel, it posts mouse movement message to user process, when it doesn't receive it, oom happens..>_<

Do i need to add total size limit of sender process's all posted message(then simply fail when buffer is full), or let the process itself allocate user space buffer to hold it(so i can paging out user space memory)?

it posts mouse movement message to user process, when it doesn't receive it, oom happens..>_<

So when userland software is broken, what do you plan on doing with it? Being strict and kill it? Ignore it and stop sending more messages? Be lenient end expect it to reply sometime soon? Designing a solution based on symptoms has a tendency to yield inferior results.

What I've done:
The kernel is responsible for allocating the message in the receiving process. This means a particular type of allocator which isn't user replaceable and the kernel controls the message pool. In order to allocate/deallocate message memory you must do a kernel call. The kernel copies the data from one process to another using a "window" in the virtual address space to the other process. This method doesn't need to temporarily store messages in the kernel address space. This is just one way to do it.

Anyway, despite this solution you may run out of memory anyway. Since the kernel knows that the receiving process is out of message pool memory, you can either return with an error code or you can put the thread on hold until memory is available again. There are many ways to do this and these are just obvious examples.

Thanks, i decide to just return error when message queue is full.

Btw l found it's really hard to implement IPC correctly. I've written many lines of code to check special situations(blocking process get killed or waked up by signals), to make it gracefully fail, handle timeout etc.. It sucks.

Hi,

orafy wrote:Thanks, i decide to just return error when message queue is full.

If the message queue is full, then is it because the sender (or senders) are flooding the queue, or is it because the receiver isn't responding quickly enough (e.g. locked up or something)? It would be nice to detect the latter case and kill the receiver if it has locked up.

orafy wrote:Btw l found it's really hard to implement IPC correctly. I've written many lines of code to check special situations(blocking process get killed or waked up by signals), to make it gracefully fail, handle timeout etc.. It sucks.

If you mix asynchronous with synchronous, then there's probably twice as many special situations you have to check for and handle (compared to "all asynchronous" or "all synchronous").


Cheers,

Brendan