On Tue, 22 Feb 2000, Jamie Lokier wrote:
> Dean Gaudet wrote:
> > i think it's better to have a per-task setting which means "use a fd free
> > list and don't guarantee me any lowest numbered fd semantics please".
>
> That has problems if you link with a library that requires the lowest
> numbered fd semantic. I'm guessing mod_perl is such a library, if you
> have a script which spawns another process. Sure you can fix the
> library, but what happens when you're simply calling code you don't want
> to change?
i've started to take on a "tought luck" attitude -- we're dealing in areas
where the unix API is slightly wrong, and few folks actually use these
features. (we use the feature in apache to work around a bug in solaris
libc though ;) and part of my logic is saying that if you do have an app
with such arcane requirements then by all means run it in its own special
process and communicate with it via HTTP and don't worry about it
polluting your high-performance critical path code with silly
restrictions.
> Perhaps a socket option on the listening socket would be better.
nah i like the clone flags.
i'm just pointing out that in addition to accept(), open() and socket()
(oh and pipe()) also create fds :)
for open() we could add an O_FREELIST or O_FREEDOM or something. we'd
have to create a new socket2() to add a flags argument.
> > p.s. i've brought up the tcp proxy as an important application in the past
> > and it's been pooh-poohed... but it's becoming more important. apache is
> > a monolithic server and it's becomming more and more difficult to link in
> > everyone's favourite library. a much more scalable (in the software
> > management sense) approach is to use a bunch of distinct webservers, each
> > handling a portion of a urlspace. the direction things are headed is that
> > we'll have a very efficient front-end HTTP proxy/cache which communicates
> > with several backend dynamic servers. see zach's phhttpd work for
> > example.
>
> One day this will be called "layer 5 routing" and every switch worth
> paying for will do it in hardware... :-)
:)
in some configurations the switch would need to have hard storage...
because one of the functions of this light front-end is static file
service (or cached "almost static" serving where a dynamic backend gives a
cacheable HTTP response and the proxy doesn't need to re-request it
again).
the basic criteria i have for this type of front-end is that if the box
running it dies, you can just put a newly formatted/installed box in its
place, and you haven't lost any data. the philosophy is that an ops team
can just keep a bunch of these around as hot spares and use layer-2
routing to throw the packets at whichever one is live. it works pretty
well in practice. these front-ends essentially never die, it's always the
backends which kick over.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:32 EST