OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Oct 18, 2017 12:32 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Signals using IPC
PostPosted: Thu Mar 16, 2017 8:23 am 
Offline
Member
Member

Joined: Thu Aug 18, 2016 12:54 pm
Posts: 25
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?


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Thu Mar 16, 2017 12:39 pm 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 718
Location: Tallinn, Estonia
By using SendSignal IPC?

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

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Thu Mar 16, 2017 7:45 pm 
Offline
Member
Member

Joined: Thu Aug 18, 2016 12:54 pm
Posts: 25
dozniak wrote:
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?


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Fri Mar 17, 2017 2:07 am 
Offline
Member
Member

Joined: Wed Oct 26, 2011 12:00 pm
Posts: 144
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.

_________________
MollenOS Progress: Hybrid Microkernel Conversion.
GitHub


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Fri Mar 17, 2017 4:40 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 342
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.


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Fri Mar 17, 2017 7:12 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 181
Location: Ukraine, Bachmut
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).

_________________
future big goal: ANT - NT-like OS for mips, arm and x86 (and, possibly, ppc and itanium, hehehe).
current smaller goal: efify - UEFI for a couple of boards (mips and arm).


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Fri Mar 17, 2017 10:51 am 
Offline
Member
Member

Joined: Thu Aug 18, 2016 12:54 pm
Posts: 25
Korona wrote:
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.


Top
 Profile  
 
 Post subject: Re: Signals using IPC
PostPosted: Fri Mar 17, 2017 2:37 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8113
Location: At his keyboard!
Hi,

dream21 wrote:
Korona wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 16 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group