home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / next / programm / 6048 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.2 KB
  1. Path: sparky!uunet!overload!dillon
  2. From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Re:  How to PANIC a NeXT (mach kernel bug )
  5. Distribution: world
  6. Message-ID: <dillon.0ndb@overload.Berkeley.CA.US>
  7. References:  <1992Sep1.211133.21384@news.lrz-muenchen.de> <1992Sep2.131055.25827@jhunix.hcf.jhu.edu>
  8. Date: 7 Sep 92 18:52:59 PST
  9. Organization: Not an Organization
  10. Lines: 42
  11.  
  12. In article <1992Sep2.131055.25827@jhunix.hcf.jhu.edu> audley@jhunix.hcf.jhu.edu (Christopher D Audley) writes:
  13. >In article <1992Sep1.211133.21384@news.lrz-muenchen.de> jolly@next2.cis.uni-muenchen.de () writes:
  14. >>I think it is very useful to know, that the NeXT-Mach Kernel
  15. >>does not support more than 2oo threads !
  16. >[..munched..]
  17. >>I don t know if 3.o solves that kernel-bug. ( using 2.1 )
  18. >
  19. >This is not a bug.  All operating system kernels have resource limits. Congrats,
  20. >You've discovered one of mach's.  There's more than one way to kill a kernel by
  21. >exceeding its limits, many I'm sure will remember that oldie but goodie
  22. >"while(1) fork() ;".  You have to program around these limits, you can't just
  23. >claim its a bug and push it onto someone elses plate.    I don't remember
  24. >which header file contains a macro indicating the max number of threads per
  25. >task, but I do know it exists ( anyone care to jump in with that info? ).
  26.  
  27.     The fact that it crashes the kernel *is* a bug, however.
  28.  
  29.     I've noticed that the NeXT, 3.0 included, appears to ignore
  30.     many of the resource limits (limit command from CSH).. it
  31.     looks at the coredumpsize and stacksize but completely ignores
  32.     datasize and memoryuse.
  33.  
  34.     This is exceedingly dangerous NeXT!  It means that *one* process with a
  35.     memory leak can crash the machine.    I'd rather just the one process go
  36.     away instead, thank you!
  37.  
  38.                 -Matt
  39.  
  40. >-=Chris
  41. >
  42. >--
  43. >Christopher D. Audley               Internet: audley@jhunix.hcf.jhu.edu
  44. >Elec & Comp Engineering              -= NeXTmail Welcome =-
  45. >The Johns Hopkins University           Phone: (410)889-3639
  46.  
  47. --
  48.  
  49.     Matthew Dillon        dillon@Overload.Berkeley.CA.US
  50.     891 Regal Rd.        uunet.uu.net!overload!dillon
  51.     Berkeley, Ca. 94708     ham: KC6LVW (no mail drop)
  52.     USA             Sandel-Avery Engineering (702)831-8000
  53.  
  54.