Profile

Cover photo
Andreas Hartmetz
128 followers|1,587 views
AboutPostsPhotosVideos

Stream

Andreas Hartmetz

Shared publicly  - 
 
An idea for IPC

In any IPC situation with untrusted senders, there is the problem that
the wire format of messages needs to be validated by receivers.
This might be done in a message routing daemon or in all receivers.
If the message is validated once by the routing daemon, it is time
spent by a time-critical process. If the message has many receivers
and receivers validate the messages, validation overhead is multiplied.

Today it occurred to me that an OS feature could eliminate the overhead: If the sender can make cheap calls to a differentprotection domain that is controlled by the IPC library ("embassy" of the receiver process/es), and that protection domain can prove to the receiver that it is the sender, then the receivers don't need to do any validation at the protocol level. Exokernels might be able to do this, I haven't looked at them enough but that is where I got the idea of more fluid memory protection borders.
The problem is that mainstream operating systems, that can execute binaries, running on any CPU architecture that I know, have no way to have different memory protection domains in one process. I don't see how it could be done with low enough overhead to make sense.

Of course I know that one domain of memory protection is more or less part of the modern definition of a process, but I don't think this is an unchangeable law of nature. One flow of control used to be part of the definition of a process, then came threads. What I'm proposing is the counterpart to threads, several lightweight memory protection domains, one flow of control.

If it could be done, I think more interesting techniques using the mechanism would be discovered. It might help streamline CPU-GPU communication in GPGPU computing, for example.

Any suggestions how it could be done?
1
Michael Pyne's profile photo
 
I would imagine that a "different protection level" scheme would use a separate mmap(2) flag but that the kernel could make it work without too much additional difficulty.

On the other hand it might be possible to use the new process_vm_{read,write}v functions to make using separate processes not quite as painful.
Add a comment...

Andreas Hartmetz

Shared publicly  - 
1
Add a comment...
Have him in circles
128 people
Marco Martin's profile photo
Martin Aumüller's profile photo
Boyer De La Giroday Michel's profile photo
Dominik H's profile photo
Bertjan Broeksema's profile photo
Frank Karlitschek's profile photo
Helio Castro's profile photo
Valorie Zimmerman's profile photo

Andreas Hartmetz

Shared publicly  - 
 
It just occurred to me that there is no major hype in its prime in computing / IT right now.

The cloud isn't super hot anymore, JavaScript is just okay, functional programming is sometimes useful, there is no new Apple device. NoSQL is in backlash mode. Nobody is talking about Web 2.0 anymore. HTML5 has leveled off before it has even been standardized (in case you didn't know, it is still not an official standard). Gamification looked hopeful for a short time but it never even took off.

Other things that are "over": Ruby on Rails, AJAX, Java, Agile as an, ahem, enterprise-class methodology, Object-Oriented Programming, Aspect-Oriented Programming,, Service-Oriented Architecture, OLE-style component frameworks.

The strange thing is that nothing is currently seen as the solution to all problems. Maybe our industry has matured. it's fairly new and things are bound to get better. Its cultural understanding, that everybody understands the basics, is still making progress. It is also fairly diverse now so there can hardly be just one dominating hype.

I say the next big thing will be Linux on the desktop, and I'm only 65% kidding.

References:
http://en.wikipedia.org/wiki/Hype_cycle
2
Add a comment...
People
Have him in circles
128 people
Marco Martin's profile photo
Martin Aumüller's profile photo
Boyer De La Giroday Michel's profile photo
Dominik H's profile photo
Bertjan Broeksema's profile photo
Frank Karlitschek's profile photo
Helio Castro's profile photo
Valorie Zimmerman's profile photo
Links
Contributor to
Basic Information
Gender
Male