Quote:
Does this stream have anything to do with the stream threads A and B are reading/writing to in your example, or is it a different stream altogether? Also, if the kernel "blocks" on a stream, that says to me that it would cause a page fault. I think your kernel would therefore have to handle page faults in kernel-mode as well. In this case, you have sort of a "kernel process" with "kernel threads" that can block, as well as the "real kernel" that runs in a purely event-driven way. This is pretty heavyweight stuff for a microkernel IMO.
It is a different stream altogether (I think I am failing to explain everything here correctly). Yes, this does mean there may have to be kernel threads, but isn't this an advantage? It means that functions implemented in the kernel could be implemented elsewhere at very little cost. Why would it make the kernel much heavier though? It can't be that costly to allow it to have it's own threads, and there has to be a part that handles exceptions anyway so the (relatively small) event driven bit cannot be escapen.
Quote:
Since threads "block" by causing page faults
Ok, I have may have mis-explained here. Threads block by telling the kernel to block on them (through the kernel stream as mentioned before).
Quote:
In other words, if thread A was writing to a page when it "blocked", the scheduler would have to change the permissions on that page to make it read-write before resuming thread A
Yes, that is the case. It would work as follows:
Thread A tries to write to stream A -> page is marked as read-write, so exception is called -> page-fault handler detects, through the memory location, that a stream caused the page fault and so forwards the information to the stream manager part of the kernel -> stream manager detects that stream was blocked on -> after checking permissions, marks streamA as read/write -> wakes up blocked threads -> resumes threadA
Quote:
That sounds like polling too. The latency could get pretty bad, plus polling wastes CPU time.
Ok, that's why the blocking idea is there, so if a thread is waiting for something, it can block. however, it may not be the most efficient solution.
Quote:
I would suggest instead just going with the traditional microkernel approach -- put your OS services in user-land processes, and have system calls for IPC.
Ok, I'll certainly try to take that into account!
Quote:
Otherwise, the rest of this just looks like a solution in search of a problem. Why are you trying to avoid system calls in the first place?
Ok, at first my design was based on the concept of IPC through shared memory, where the kernel interferes very little (making it faster that having to invoke the kernel for each message pass occurs). This was intended for applications that transfere a large amount of data between each other (for example the different network layers) as opposed to events. Of course, as part of the design, I need to evaluate precisely how much kernel 'interference' would be usefull as opposed to counter-productive. I also wondered about extending my abstrction as far as possible, by making streams the ONLY way of communicating with anything, even the kernel. There are some reasons that the kernel should 'officially' be only accessible by streams, though they are beyond the scope of this post (since they would have to be explained as well).
Thanks,
OScoder