From: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
Newsgroups: comp.sys.sgi
Subject: Re: Bug in SGI's malloc?
Date: 15 Oct 92 10:38:50 GMT
Reply-To: cmaae47@cc.ic.ac.uk
Organization: Imperial College of Science, Technology and Medicine


In article <1992Oct13.190027.4398@sol.ctr.columbia.edu>, shenkin@still3.chem.columbia.edu (Peter Shenkin) writes:
- In article <Oct13.182113.66166@yuma.ACNS.ColoState.EDU>
-  jamison@yuma.ACNS.ColoState.EDU (Jamie Gulden) writes:
- 
- >I don't mean to harp on this (well, maybe I do) but I do not
- >agree with the default sgi malloc implementation.  However, I
- >do agree with the guy who asks for a way to control it on a
- >per process basis....
-
Even that would not help, see below.
..... 
- However, the signal sent by the system is a KILL, which cannot be
- trapped;  therefore there is no way to do this.  So the best I can
- do is:
- 
- 	Print a message to the effect:  "If <program-name> is killed
- 	by the system before the next output, you have insufficient
- 	memory+swap to run the job on this large a data set."
- 
- 	Touch malloc pages.
- 
- 	Print a message to the effect: "Whew -- you made it."
- 
- Furthermore, there is no way I can even detect at run time what
- the behavior of the machine I am running on is -- or is there?

If you want to write a portable and predictable application it is the 
other processes in the system you have to control, not your own ones, 
which (of course) use memory conscientiously :-).

One approach you could try is to create 'drones', subprocesses which just
allocate memory and deliver it to the parent process. When the system 
decides it does not have enough memory and goes into 'Rambo mode', you 
could afford to loose some of them without suffering instant death for
the application. If you make these drones intelligent than any one could
turn into the 'queen', write out the error message and exit gracefully, 
or hang on to whatever resources it can get out of the system.

See the Robin Hood and Friar Tuck story recently in comp.unix.admin.

- Speaking more philosophically, (1) people who claim to need this
- behavior to allocate sparse matrices, only parts of which are
- actually accessed, should be shot;  they should be using sparse-
- matrix storage techniques.

Telling users yo go away when they want to buy your machine (or shooting 
them) will not make for a commercial enterprise.
.....
- (2) what was wrong with requiring people who suffered from the fork()
-  problem to use vfork(), which IRIX no longer supports?

fork() is part of the POSIX standard and vfork() is not. Furthermore,
the people who wanted (nay, demanded) delayed virtual memory realisation
behaviour are using FORTRAN and do not call fork() or vfork() directly.

- In any case, the whole problem points out real deficiency in the very 
- concept of fork() as a general mechanism for spawning a new process -- 
- and this seems to me to be a real deficiency at the heart of UNIX.

Hmm, they actually call it a feature. It is so nice to include the phrase:

if (fork()) exit(0);

into the program to give the feeling of instant success. OS-9 does not have 
fork() and people are VERY unhappy about that.

                                         Thomas
-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain