From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 4 Dec 2009 22:09:46 -0700 From: Lyndon Nerenberg To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <45bb8a0916edcb2ee86883ebeea8945e@brasstown.quanstro.net> Message-ID: References: <> <45bb8a0916edcb2ee86883ebeea8945e@brasstown.quanstro.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [9fans] ideas for helpful system io functions Topicbox-Message-UUID: a81c0d28-ead5-11e9-9d60-3106f5b1d025 > the standard way of passing file descriptors is by fork/exec. > this allows security is handled by the normal means. Where FD passing is useful is to avoid that fork/exec overhead. The apps I was working on had a relatively simple front-end process that would field requests that required data to be crunched in various ways. Some of this crunching had *very* high overhead relative to the volume of requests coming in. Fork/exec simply would not scale. Instead we wrote long-lived backend processors, and let the front-end act as a connection multiplexor, handing the FDs from the incoming requests around as required to crunch the data. This significantly reduced the system-related overhead, and also made it very easy to chain filters together with the front-end managing the whole thing from a single configuration file. > this case would be handled by fork/exec. the general case is > handled by srv(3). Well, srv(3) in reverse ... sort of. I've been thinking about doing something like this for a while now, specifically for httpd. What I've been scratching my head over is if the handoff between httpd and the backends should be a raw file descriptor, or a 9P interface. I need to scratch together a prototype to experiment with but there's too much on my plate right now. --lyndon