OSDev.org

Posted: **Thu Jan 20, 2005 10:48 am**

Heya everyone.

I'm now done with my "redesign" of Clicker's message passing architecture, which is now based on ports abstraction (like much other microkernels) rather than on purely asynchronous events and handler functions (which sucked big time)

You can see it at
http://clicker.sourceforge.net/wiclicke ... tsProposal

I'd be interrested by your feedbacks, esp. from those who have fought with message passing in their own OS (BI?)

The main design lines are:
- every message is addressed to a single port and each port is owned by a single thread.
- each thread has its own mbox to store one pending message, but for asynchronous message, the emitter has the option to get a temporary mbox so that its own mbox remains free for other purpose
- a thread may listen on several ports at the same time and being notified as soon as one of those ports receives a message.
- a thread may send a message on P1 and tell the system it wishes a reply on another port P2 (to implement RPC-like things)

Only short fix-sized messages are considered here so far. Larger messages can easily be constructed by passing a short message with "memory reference" that allows the receiver to map emitter's frames.

I don't try to have zero-copy message passing atm.

Posted: **Fri Jan 21, 2005 2:04 am**

Hehe, that's way cool, I daresay, f. ex. for the IPC between services and user processes.

My imagination goes even so far that upon creation of a message port we add an entry in some subsystem which makes the port public to the system - so that other processes can access the port.

This way you don't need to know about the id of the task you send a message to, you only need to know about the id/name of the port you intend to write to.

It is a kind indirection - the underlying mechanism remains rather the same - we take a message and deliver it to the receiver - but it is no longer bound to having to know specific task id's. we can communicate the receiver our own port if we wish a reply and then we receive on this port.

by the way: If I understand correctly, you want to provide message queues for async messages, right? Good. I'd prefer it this way too.

if posting syncronous messages, you copy the content of the message into a holder place inside kernel land and enqueue the sender to the list of "I wanna send to you and can't"-processes and block it - because the receiver isn't currently receiving on the port in question. Good. This way we don't need to care about "I want to receive from XXX". I tell the receiver: gimme answer to port YYY and then I receive on port YYY.

We can have this operation in one flush too:

in kernel land: sendrec: do_send. If do_send returns zero (success): msg.receive_on is set: do_receive(msg.receive_on,&msg); Gonna have to explore this.

Gonna read throu the paper more intensive this weekend.

stay safe.

Posted: **Fri Jan 21, 2005 3:50 am**

yep. i'm planning to have additionnal operations

Code: Select all

// deliver the message to send_port, then wait on reply_port
// until the owner of send_port replied.
// this is handy for RPC-like calls.
send_msg_and_wait_reply(&msg, send_port, reply_port);

// deliver a message containing a reply to a given reply_port
// once this is done, try to recieve another message on the 
// recv port. if that new message requests a reply, we get its
// reply_port as return value
reply_port=send_reply_and_recv(&msg, reply_port, recv_port);

OSDev.org

messages forwarding for microkernels

messages forwarding for microkernels

Re:messages forwarding for microkernels

Re:messages forwarding for microkernels