Nicolas Williams' source environment variables

[Nicolas Williams]

On Thu, 3 Feb 2000, Luke Kenneth Casson Leighton wrote:
> > One concern I have about including the output of executables is that this 
> > means an additional fork()ing and exec()ing of a program for every such 
> > include done--for every time smb.conf is read. I imagine there are others 
> > here who have a better idea than I of how much overhead this represents, and 
> > perhaps you can put my mind at ease :), but at present, I would hesitate to 
> > use such a feature for fear of a performance hit.. 

Well, lp_load() checks the list of files included/to-be-included to see
if their timestamp has changed. This means that pipes would only be
included once (sigh) unless pipes were to be included everytime
lp_load() is called instead.

Luke suggested a new include-like parameter to allow inclusion of file
whose names depend on %u. So I'll take that as a cue and suggest that
all we need is a way to indicate wether a pipe is to be included once or
more than once.

For the purposes of generating a set of shares from automounter maps (as
someone else said they are trying to do) including a pipe only once is
just fine.

For other purposes a combination of 'preexec' and 'include' or the use
of Luke's proposed 'share include' (if it allows inclusion of pipes on
share connects but not at other times) should do.

> on startup. 
> 
> on a TCP connection (at least twice) 
> 
> on NetBIOS session request 
> 
> on SMBnegprot 
> 
> on SMBsesssetupX (at least twice) 
> 
> on SMBtconX 
> 
> there may be more [triggered by incoming network traffic, that is]. 

Right, but executables rarely change! (See above :)

> there's also a stat cache which can result in a reload of smb.conf and all 
> other included files -- that's every single smbd process running at the 
> time -- all within a ten second period or so (depending on the state of 
> the indicidual smbd processes, but at least SMB_IDLE_LOOP_TIME seconds). 
> 
> so, potentially, it's a really, really large performance hit. we've been 
> sufficiently concerned about it [and the associated memory reallocation of 
> all the parameter strings], that we've wanted to have an "smb.conf 
> parameter cache" for at least three years. 
> 
> the idea being that only those parameters that have *changed* get 
> realloc'd. 
> 
> dan [ef.], sorry for earlier comments of mine: i want to encourage ideas 
> not squash them, that's not my job or authority to do that. 

So don't squash them. Anyways, you're doing fine. The issue of when pipe
includes should be reloaded is one I had not thought of.

> luke 


Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.