Signals using IPC

[dream21]

Majority of us work on microkernels in which IPC is the heart of the kernel. If we don't want to depend on POSIX signals to transfer interrupts/exception like SIGINT or SIGKILL to the process, how can it be done using IPC?

[dozniak]

By using SendSignal IPC?

You need to IPC to a specific thread (exception handler thread or somesuch).

[dream21]

By using SendSignal IPC?

You need to IPC to a specific thread (exception handler thread or somesuch).

If I have to send a signal(using IPC) to a process to kill it, how can it be done?

[MollenOS]

The thing is, to implement such a thing as exceptions you need to be able to interrupt the execution context of a thread - one option (the typical option) is to do this using signals. You could just as easily implement this using IPC messaegs (actually signals is a form of IPC) - however you still need to implement partial support for signals due to the fact they must work almost identically under the hood, and that is to have the ability to interrupt a currently running thread by hi-jacking it and making it execute at a new place.

This is my understanding, and if anyone knows something please feel free to correct me.

[Korona]

You obviously cannot deliver synchronous faults (e.g. SIGSEGV) via IPC messages to the same thread that caused them. You could deliver them as messages to some other thread (e.g. a "process server" or watchdog thread).

That being said what makes you think that microkernels cannot support POSIX signals? I don't think POSIX signals are a particularly appealing feature (admittedly I don't think it is easy to come up with a better design that fits into the POSIX context) but there is nothing that prevents you from implementing them in a microkernel.

There are numerous possible designs: For example my kernel does not have signal interfaces at the kernel level. It does have system calls to manipulate execution contexts though and implements POSIX signals in user-space.

[zaval]

hehe, don't know. I am working on an NT-like, hybrid kernel. And for the POSIX subsystem "signals", they are going to be delivered through APC of course.
Couldn't microkernels take advantage of APC too? NT stops threads through it as well. With APC you can run any needed code in the context of a particular thread (and its process' address space among it).

[dream21]

You obviously cannot deliver synchronous faults (e.g. SIGSEGV) via IPC messages to the same thread that caused them. You could deliver them as messages to some other thread (e.g. a "process server" or watchdog thread).

That being said what makes you think that microkernels cannot support POSIX signals? I don't think POSIX signals are a particularly appealing feature (admittedly I don't think it is easy to come up with a better design that fits into the POSIX context) but there is nothing that prevents you from implementing them in a microkernel.

Actually, I was looking at HelenOs which is not unix and strictly does not implement POSIX. I am not thinking of SIGSEGV right now, only SIGINT or SIGKILL.

[Brendan]

Hi,

You obviously cannot deliver synchronous faults (e.g. SIGSEGV) via IPC messages to the same thread that caused them. You could deliver them as messages to some other thread (e.g. a "process server" or watchdog thread).

That being said what makes you think that microkernels cannot support POSIX signals? I don't think POSIX signals are a particularly appealing feature (admittedly I don't think it is easy to come up with a better design that fits into the POSIX context) but there is nothing that prevents you from implementing them in a microkernel.

Actually, I was looking at HelenOs which is not unix and strictly does not implement POSIX. I am not thinking of SIGSEGV right now, only SIGINT or SIGKILL.

If you're working on a micro-kernel that strictly does not implement POSIX, then you should probably be working on a micro-kernel that strictly doesn't implement signals. For example, you could just have a "please terminate" message (possibly with some kind of "why you're being asked to terminate" field or other information in the message) and let the thread/s handle it the same as they'd handle any other message.

Note that for asynchronous messaging (where you have a queue of messages waiting to be received) it can be a good idea to allow some types of messages (that are sent from the kernel) to jump to the head of the queue. Specifically, I'd want to do this for "IRQ occurred" messages (to improve performance of device drivers), for the "please terminate" message (so the OS can free up resources a little faster), and for any "obituary messages" used to inform a thread that some other thread or process was terminated (so it stops trying to communicate with the terminated thread sooner).

If a process actually does want asynchronous signals (but not synchronous signals); a process could emulate it themselves by having a generic message handler that handles (or discards/ignores) any messages that weren't already handled (e.g. for "switch(messageType) {" you might have "default: handleMessage(); break;"); where that generic message handler emulates signals by allowing you to set callbacks and by calling those callbacks if/when a suitable message arrives.


Cheers,

Brendan