thinman@cup.portal.com (Lance C Norskog) (08/07/90)
I've heard through the grapevine, but am not sure yet, that UNIX V.4 shared libraries are fully paged, that is, you don't have to have the whole library in RAM when a program was using it. (As opposed to the sorry situation in UNIX V.3) If this is true, do V.4 ports of X just stuff the server into a giant shared library? This cuts the overhead of the local transport down to a subroutine call. (Well, maybe not.) You need to have each run-time copy of the code share control of the screen, using a semaphore (or two to avoid race conditions) for a baton will do the trick. To accept network connections, you still want to have an official X server process; it will be handy to keep an official server process around as a figurehead, and rig things somehow so that killing that process shuts down the shared library ghosts. Has anyone announced something like this?
guy@auspex.auspex.com (Guy Harris) (08/08/90)
>I've heard through the grapevine, but am not sure yet, that UNIX V.4 >shared libraries are fully paged, that is, you don't have to have >the whole library in RAM when a program was using it. (As opposed >to the sorry situation in UNIX V.3) Is that *really* the case in S5R3? In any case, S5R4 shared libraries are SunOS 4.x shared libraries with sugar and cream on top, basically; they are fully paged. >If this is true, do V.4 ports of X just stuff the server into a giant >shared library? I would be extremely surprised if they did; I don't think it's a trivial change, since... >You need to have each run-time copy of the code share control of the >screen, using a semaphore (or two to avoid race conditions) for a baton >will do the trick. ...and they'd have to share control of assorted global data structures as well. In addition, doing the locking necessary to enable the N processes to share the screen and other data structures could conceivably squander any performance gain you get from not doing IPC to a separate server process....