OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 5:42 am

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?

_________________
drugstore-onlinecatalog.com


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: 723
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?

_________________
drugstore-onlinecatalog.com


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: 202
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 | gracht (protocol library) | vioarr (window-manager) | bake (package manager)


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: 999
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.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


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: 640
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).

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


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.

_________________
drugstore-onlinecatalog.com


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: 8561
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: Bing [Bot], DotBot [Bot] and 67 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