An Implementation of the Solaris Doors API for Linux (1998) [pdf] | Hacker News Reader

An Implementation of the Solaris Doors API for Linux (1998) [pdf]

rampant.org

37 pointstodsacerdoti11 comments

Jason Lango, the original author (who I know personally), came from Brown University. Back in 1998, Brown was an 95%-Solaris shop, and so Solaris-specific APIs like Doors, its flavor of /proc, and its unique two level thread model (later removed by the late great Roger Faulkner) were topics of great interest amongst the systems students.

For at least one semester, the student operating system project was known as DoorsNT.

Related: Doors API for modern FreeBSD

https://github.com/bnovkov/freebsd-doors

Neat! There’s some Solaris stuff in FreeBSD already, like ZFS and DTrace.

I am not familiar with the doors api, but if there is some real advantage to it, perhaps that patch could be included into FreeBSD upstream?

The key advantage of the doors IPC system is that it tries to be a synchronous IPC system, and whenver it can operate synchronously it can do things like:

  - immediately context switch to the
    server to reduce latency
  
  - transfer the caller's priority to
    the server to avoid priority inversion
    problems

The downside of doors is that the server really has to be able to satisfy all requests very quickly, and if not then the client and server need to agree on an asynchronous completion notification mechanism (e.g., pass a fildes from the client to the server). And there's no guarantee that all requests can be handled synchronously. But there's a significant number of system services for which it is possible to have very fast, synchronous protocols, and for those doors really shines because of the thread shuttle and priority transference.

Its main use case was connecting to nscd, the name service caching daemon, and serve a name lookup without incurring context switch latency.

I made a similar doors api implementation for Linux in 2001 (https://ldoor.sourceforge.net/). It eliminated the cost of having a thread pool and context switches by re-using client thread and replacing its MM context with the server context, so that the thread magically finds itself within another process.

Right, I thought that was the whole idea, like a shuttle?

It is.

Original Solaris doors use server thread pools: https://github.com/illumos/illumos-gate/blob/master/usr/src/...

Yes, but because when a server thread is available the context switch is immediate and with priority transfer, the effect is similar.

I agree that the direct hand-off that Solaris shuttles provide is more efficient than general wakeup, but it is less efficient than switching MM context of the client thread. The latter results in twice fewer threads, twice fewer scheduler lock acquisitions, etc. Note that for the kernel-level door servers, Solaris does not use server threads, it directly calls the server entry point function.

Reply on news.ycombinator.com