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

37 pointsby todsacerdoti3 anni fa11 comments

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

http://www.rampant.org/doors/linux-doors.pdf

3 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.

yjftsjthsd-h3 anni fa

Related: Doors API for modern FreeBSD

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

codetrotter3 anni fa

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?

cryptonector3 anni fa

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.

fmajid3 anni fa

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

oecumena3 anni fa

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.

lukeh3 anni fa

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

cryptonector3 anni fa

It is.

oecumena3 anni fa

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

cryptonector3 anni fa

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

oecumena3 anni fa

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.