Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!olivea!mintaka.lcs.mit.edu!ai-lab!hal.gnu.ai.mit.edu!mycroft From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum) Newsgroups: comp.os.386bsd.bugs Subject: Re: VM problems w/unlimited memory? Message-ID: <1oh2j3INN44j@life.ai.mit.edu> Date: 21 Mar 93 06:39:31 GMT References: <1o81joINNieh@usenet.INS.CWRU.Edu> <1993Mar18.183443.6397@fcom.cc.utah.edu> <1obpil$aq7@hal.gnu.ai.mit.edu> <1993Mar21.002245.2246@fcom.cc.utah.edu> Organization: dis Lines: 54 NNTP-Posting-Host: hal.ai.mit.edu DAMN IT, Terry, you are totally ignoring what I am saying! In article <1993Mar21.002245.2246@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: } } In article <1obpil$aq7@hal.gnu.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu } (Charles Hannum) writes: }> }> No, he's going strictly by the book. If the kernel wants to say }> `Sorry, out of memory.', that's fine, but crashing is totally }> unacceptable. Whether this would cause a performance problem for }> bash or not is bash users' concern. } } Agreed on the performance problem for bash being bash's problem; } disagreed that the use of an unnecessary amount of memory on some } systems due to inapropiate assumptions about architecture will not } cause problems for other non-bash-users on the sharing the same } system. THIS IS WRONG. You are ASSUMING that using a high file descriptor number will cause the kernel to allocate a large amount of memory. This may be the case in *one* or even a *few* kernel architectures, but it IS NOT a requirement. In fact, other systems get it right. }> What *you're* saying is that he should take the kernel architecture }> into consideration, when in fact he's doing something perfectly }> valid. } } I disagree; bash isn't trapping the "ENOMEM" which would result from } the "corrected" 386BSD open/dup/dup2 calls, nor is it repicking an fd } lower until job control can function properly. In any } implementation, the bash code will be required to change. I DON'T CARE about Bash; tell Chet privately. It's not even relevant to this group! }>> There doesn't seem to be a good reason for this if the shell script }>> is in core in the shell; it should be closed after reading. Since }>> reading takes place entirely before execution, there is no conflict }>> with the shell script itself. In any event, a shell script is run }>> by a sub-shell, }> }> Look up `source' in the sh(1) man page, please. } } [JUNK omitted] You TOTALLY missed the point. With respect to `source', what you said above is completely wrong. -- \ / Charles Hannum, mycroft@ai.mit.edu /\ \ PGP public key available on request. MIME, AMS, NextMail accepted. Scheme White heterosexual atheist male (WHAM) pride!