Messages in this thread | | | Date | Tue, 22 Feb 2000 13:43:16 -0800 (PST) | From | Dean Gaudet <> | Subject | Re: accept() improvements for rt signals |
| |
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/
| |