Re: Servers vs. Libs

[Erik Dalen <erik@jpl.nu> writes:]

>But is it really preffered to put things that could be put in a server, in
>a library instead?

It depends. But, generally, it takes less code and fewer cycles to invoke a
service in a library rather than across a context switch to some other
process.

>Personally I think things that can be put in servers should be put in
>servers. The graphics is a good example, In plan9 it is in a server
>providing a device to write to. The programs don't need to be aware at all
>of which graphics hardware there is in the computer.
>But if it is put in a library instead, it can't be multiplexed (ala 8.5
>and rio). But probably worse, you would have to code wrappers for the
>graphics library to each programming language you'd want to code graphics
>in.
>And for those that preffer coding graphics by calling functions instead of
>writing data to a device, a library for drawing that uses the
>device(server) could be coded.

Except that almost every "serious" graphics program does the inevitable
genesis to the point where it wants memory mapped access to the frame
buffer. And I'm not really arguing much, since the MGR port could call the
main mgr process the "graphics server", and then all clients are in their
own address spaces. But, then, MGR is linked with svgalib to actually
control the graphics card, so that's adopting the other rule.

The other big question is state management. Multiplexing is one (thus, mgr
has its own process). But even in a single client case, the complexity of
state and requirements for cleanup (i.e., on a segv hardware needs to be
un-programmed) might argue for a distinct process.

Any rule can be applied in such a way that it doesn't make sense. I don't
see any problem with your arguments.

Andy Valencia
Received on Sun Feb 11 12:06:51 2001