Messaging
Messaging
Is there a reason why kernel needs to send or receive messages from other processes? I mean I think kernel does not really need to act in IPC since it can communicate with user threads with system calls, right? So is it the case that IPC is used only to make user threads, in general: the threads with seperate address spaces, communicate with each other? Or am I missing something?
Re:Messaging
IPC is for messaging between threads (as the name suggests). You can use syscalls so that processes send stuff etc.
Pete
Pete
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Messaging
threads from the same process can communicate with each other by simply writing/reading to main memory. Most of the time, they request assistance from the kernel for synchronizing with each other.
IPC come in play when you want to communicate with threads in other process (hence the name, Inter-Process Communication), and only the kernel will be able to allow such behaviour by setting up shared areas or relaying messages.
Since threads can issue requests to the kernel, it may occur that the kernel needs to notify threads from some unrequested events such as kill command, etc. This is most traditionnally handled by signals but it could use IPC aswell if the response to the notification isn't required to be immediate.
IPC come in play when you want to communicate with threads in other process (hence the name, Inter-Process Communication), and only the kernel will be able to allow such behaviour by setting up shared areas or relaying messages.
Since threads can issue requests to the kernel, it may occur that the kernel needs to notify threads from some unrequested events such as kill command, etc. This is most traditionnally handled by signals but it could use IPC aswell if the response to the notification isn't required to be immediate.