illumos-gate

but someone would need to check. That said, I have to recant my previous comment. smw likely linked the directory, which is insane, but would have worked on older Solaris versions if we assume the modern illumos UFS driver is unchanged in this regard.

and "private" pool of threads. By default threads are pulled from the global pool to service requests, but if you specify DOOR_PRIVATE to door_create, it uses the private pool bound to the door. AFAICT, this is conceptually a typical worker thread pooling implementation, with condition variables, etc for waking and signaling. (See door_get_server at https://github.com/illumos/illumos-gate/blob/915894e/usr/src...) Context switching does seem to be optimized so door_call doesn't need to bounce through the system scheduler. (See shuttle_resume at https://github.com/illumos/illumos-gate/blob/2d6eb4a/usr/src...) And door_call/door_return data is copied across caller and callee address spaces like you'd expect, except the door_return magic permits the kernel to copy the data to the stack, adjusting the stack pointer before resuming the thread and resetting it when it returns. (See door.S above and door_args at https://github.com/illumos/illumos-gate/blob/915894e/usr/src...) This works just as one might expect: no real magic except for the direct thread-thread context switching. But that's a similar capability provided by user space scheduler activations in NetBSD, or the switchto proposal for Linux. The nomenclature is just different. It's a slightly different story for in-kernel doors, but that's not surprising, either, and there's nothing surprsing there, AFAICT (but I didn't trace it as much). Thanks for finding those source code links. I cloned the repo and started from there, grep'ing the whole tree to find the user space wrappers, etc.

rm of a door_info_t structure. The di_proc and di_data members of the door_info_t structure can be used as a door identifier associated with the depleted pool. The create_proc procedure may limit the number of server threads created and may also create server threads with appropriate attributes (stack size, thread-specific data, POSIX thread cancellation, signal mask, scheduling attributes, and so forth) for use with door invocations. <https://docs.oracle.com/cd/E88353_01/html/E37843/door-server...> apparently things like door_create() survived into opensolaris and so they are presumably open source now? even if under the cddl <https://www.unix.com/man-page/opensolaris/3c/door_create/> /me git clone https://github.com/kofemann/opensolaris jesus fuck, 1.4 gigabytes? fuck you very much fw_lpe11002.h okay so usr/src/lib/libc/port/threads/door_calls.c says the 'raw system call interfaces' are __door_create, __door_return, __door_ucred, __door_unref, and __door_unbind, which, yes, do seem to be undocumented. they seem to have been renamed in current illumos https://github.com/illumos/illumos-gate/blob/master/usr/src/... unfortunately it's not obvious to me how to find the kernel implementation of the system call here, which would seem to be almost the only resort when it isn't documented? i guess i can look at how it's used __door_create in particular is called with the function pointer and the cookie, and that's all door_create_cmn does with the function pointer; it doesn't, for example, stash it in a struct so that a function internal to door_calls.c can call it in a loop after blocking on some sort of __door_recv() syscall (which, as i said, doesn't exist) it does have a struct privdoor_data under some circumstances; it just doesn't contain the callback i don't know, i've skimmed all of door_calls.c and am still not clear on how these threads wait to be invoked aha, the kernel implementation is in usr/src/uts/common/fs/doorfs/door_sys.c. door_create_common stashes the function pointer in the door_pc of a door_node_t. then door_server_dispatch builds a new thread stack and stashes the door_pc on it as the di_proc of a door_info_t starting at line 1284: https://github.com/kofemann/opensolaris/blob/master/usr/src/... this seems to be a structure with layout shared between the kernel and userspace (mentioned in the man page i quoted above): https://github.com/illumos/illumos-gate/blob/master/usr/src/... ...but then door_calls.c never uses di_proc! so i'm still mystified as to how the callback function you pass to door_create ever gets called probably one hour diving into solaris source code is enough for me for this morning, though it's very pleasantly formatted and cleanly structured and greppable. does anybody else know how this works and how they got those awesome numbers? is door_call web scale?

00.00 [system] 0 0 0 117 106 125 0 0 28132 pooldrai DK- ? 0:00.00 [system] 0 0 0 116 106 124 0 0 28132 syncer DK- ? 0:00.00 [system] 0 0 0 115 106 126 0 0 28132 pgdaemon DK- ? 0:00.00 [system] These are all true and authentic threads, they just don't spend any time executing userland code. The work they carry out is, respectively: to carry out I/O to/from buffers in userland, because this may incur page faults and cannot therefore be done in a soft interrupt which has no thread context; to reclaim pages from the pool (slab) allocator; to lazily synchronise dirty buffers back to disk; and to carry out page replacement. All of these listed above carry out memory management, so it is not correct to say that PID 0 "has nothing to do with memory management" or that the Wikipedia article is wrong to discuss paging as a responsibility of PID 0. That's what pgdaemon is doing! There are many other threads that are part of the kernel process (or "PID 0") on NetBSD - modern kernels generally use a lot of them to carry out all sorts of tasks. A few others on NetBSD include worker thraeds for running asynchronous I/O completions and for processing various kinds of input in the networking stack. Illumos should also be considered. Looking at its PID 0: root 0 0 1 1 0 11:22:53 ? 0:02 sched We can see it is called sched. Why sched? This article talked about the historic role of PID 0 in process swapping. Process swapping is a scheduling problem (like a lot of problems in software). This is why swappers are traditionally called medium-term or memory schedulers. Illumos generally gives most groupings of kernel worker threads their own processes with their own PIDs, but one, called "sched", remains in PID 0, and its responsibility? Process swapping: https://github.com/illumos/illumos-gate/blob/579c23696ac6891... The Wikipedia article has now been hastily edited, and replaces a claim that was true only of certain Unixes other than Linux with a claim true only of certain Unixes including Linux. Is this an improvement?