Xinetd resurrection

[Yaakov Nemoy]

2009/9/20 Lorenzo Villani <lvillani at binaryhelix.net>:
> On 09/20/2009 06:28 PM, Steve Grubb wrote:
>>
>> Not at all. These days the only need for xinetd is in memory constrained
>> systems. For mainline x86_64 bought with typically 4Gb of main memory,
>> xinetd
>> is a thing of the past. That's my point.
>>
> Well, I am probably part of that 0.000001% who would like some services to
> start on-demand.
> For example I don't print all the time and I prefer to have cups start only
> when needed, then die instead of having it waiting for no real purpose. Now,
> this is a case in which it doesn't make sense (you start xinetd instead of
> cups for no real gain) but it can be useful with some setups.
>
> Even if I have a quad-core system with 4Gb of memory available I always
> prefer to find a better use for it.

Let's be theoretical here for a second.

In our von neumann machine architecture, a process needs to be
initialized, where the code and data are read off the slow storage
into the fast storage, the code path is executed, and the run time
state is set up. In order to use the service, this process always has
to happen. While the process, a certain amount of memory has to be
used. These are fundamental issues that apply to how we use von
neumann machines.

You're discussing the process of managing the lifecycle of this core
process. When loading cups on startup, as a standalone process, this
process is done once, and then the results are stored in the memory.
When the system runs out of memory, the state of the program is pushed
back to the slow storage in the form of swap. Assuming the process is
swapped out between every run, you incur the expensive cost of
reloading the state from the hard drive. You don't incur the cost of
reinitializing the state, although there might be some relatively
minor overhead (OS handling swapping of processes, the process
updating it's state in case something else on the system has changed
since the process was paused). In the best case scenario, this never
occurs, but then a few precious megabytes of your 4GB (everyone should
be so lucky) are taken up.

If you have 4GB, not swapping and keeping the process in runtime
memory will give you the most responsiveness. If you're an end user,
this is probably what you want. If you have less, you have to make a
decision. Do we load it on start and swap it out, or do we manage it
on demand. You're basically asking this question.  Given the costs,
you're really asking the wrong question as an end user. It really
doesn't matter at all. To the end user, you're offering the user too
much choice, where the end user is not educated enough to know the
difference, doesn't care, and just wants printing to work.

Of course, there are a number of other benefits to using inetd or
xinetd pointed out in this thread. Assuming your services are KISS
compliant, meaning they're lightweight, doing everything on demand is
The Right Thing (tm). (Proving this is left as an exercise to the
reader.)

-Yaakov