Nope. At first I was thinking it was like the executive tasks that used to
exist under RSX-11D where the executive task used a trap instruction instead
of a syscall (it registered its existance with the OS, after which any user
process that used the trap instruction had the data "context" switched to
the executive task. This task could then request memory re-mapping to access
the users data space until it was finished handling the trap). This was used
in some fancy "not-quite" database applications and some real-time control
applications. Your discription didn't quite match since the user "process"
was in a wait state until the completion of the trap service, which waited
for the "executive task" to complete.
The closest thing in a Unix environment would be a shared memory RPC
implementation. This would provide fast data transfer via the shared memory
and the server process could handle multiple requests using threads. The
client process would not necessarily wait for a response, and the server
process could also complete other computation in between requests.
>Are there any OS's with a CORBA ORB built right into the kernel where these
>types of calls between two different processes are done directly instead of
>over sockets?
Not to my knowlege - the ORB is usually too large to fit. Error recovery would
be difficult to handle too - the kernel would end up not doing anything else.
>
>This may not even be possible, but no harm in asking.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/