μSystem Project http://plg.uwaterloo.ca/~usystem/
The following is a brief summary of the μSystem project, being developed at the University of Waterloo. The project is looking at development of a highly-concurrent shared-memory programming system.
Why concurrency? Why shared memory? Horizontal and Vertical Shared Memory Projects Concurrency in C μC++ Real-time μC++ Concurrent Monitoring, Visualization and Debugging (MVD) uDatabase Future Contact Teaching Source
@dabro I looked at unikernel for at least 20 hours a few years ago. I basically decided that linux servers are more efficient in CPU and memory, partly via shared libraries etc. I don't think the security advanatage is that important to me. Also, they are slow to start similar to Amazon AWS lambdas. Very cool idea though!!
What about these unikernel processes interest you? Where and what is "slack lies" in your comment above?
But you're right; the principle win is the combined low-latency, high security model, with no competing technology within reach as far as I know. If you don't need that security, in terms of minimal trusted code base and near-complete hardware isolation, then other tech like OS containers may be very competitive.
You'd also need to show me stats on Linux servers being more efficient; I don't see how at least at the micro level, since you've stripped out all process management, scheduling, generic resource management, etc.
I did say the shared libraries was the point where linux is more efficient in terms of memory re-use. Also the issue of having VMs allocated to a unikernel that does not fully use the CPU but yet has a hold of one presumably waiting for an interrupt to tell it that it has work to do. Perhaps I'm misunderstanding something but that is what makes timesharing really great. Other processes can run on the CPU. Now, if you had a unikernel fully (or almost fully) utilized, then the context switching of Linux, would start to play a larger factor. But what daemon is fully utilized? Anyway I have no stats to support my ideas and I may misunderstand the context switching and VM lanching and switching, but I'm going with my limited knowledge.
By the way, I dislike typing. I prefer to talk about these sorts of things. You did loose me in some of the other detail you typed. To get to the bottom of things I would prefer audio. My phone number is 512 Threenine 4 36twoooone. I don't have your number.
A execution_context provides the means to suspend the current execution path and to transfer execution control, thereby permitting another execution_context to run on the current thread. This state full transfer mechanism enables a execution_context to suspend execution from within nested functions and, later, to resume from where it was suspended. While the execution path represented by a execution_context only runs on a single thread, it can be migrated to another thread at any given time.
A context switch between threads requires system calls (involving the OS kernel), which can cost more than thousand CPU cycles on x86 CPUs. By contrast, transferring control among them requires only fewer than hundred CPU cycles because it does not involve system calls as it is done within a single thread.
-fcoroutines-tsCLI option. However, wasn't able to find that option in the versions I have on my machine.