🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2
Article #205

Re: Why is OS/2 a memory hog?

#205
From: jim frost
Date: Wed, 22 Nov 1989 19:10
52 lines
3016 bytes
alex@mks.com (Alex White) writes:
>In article <3189@husc6.harvard.edu> hellerst@husc7.UUCP writes:
>>Your argument about fork is very restrictive.  New technology is always
>>used in copycat ways for a while, but I submit that threads are significantly
>>more powerful than fork, and that many applications will be able to make
>>use of them to great advantage.  

>HUH?
>New Technology?

Yea, he's right.  Threading has been around a long time, you know;
many dedicated applications do it.  Personally I recognize four
execution primitives: fork(), thread(), exec(), and spawn().  Fork()
duplicates a process exactly.  Thread() duplicates a process context
and stack (please, no flames about copy-on-write and other techniques,
I'm trying to get at the essence, not the implementation).  Exec()
overwrites a process with another, and spawn() creates a new process
altogether.

These primitives go by a lot of different names, but almost everybody
recognizes that they're pretty much it for the primitives.  UNIX was
one of the first operating systems that bothered with either fork() or
thread(), and versions of UNIX have had everything but spawn for
awhile (hey, it's possible to spawn by fork then exec so why have
it?).  Just not the major versions.  Most other operating systems only
had spawn() and *maybe* exec().  I grew up with the "most other" type
operating systems and it took awhile to learn that fork() was a
powerful construct.  Thread() is even more powerful, but not a hell of
a leap from the techniques you use with fork(), especially when you
have shared memory.

Most operating systems books have discussed these primitives for years
(under various names), long before Mach and OS/2 and other threading
operating systems were around.  It's primitive stuff, nothing new
here.  The only thing new about it is that people are actually
starting to put it in the operating system and not in the application.
A natural step.  Hell, it took 'em long enough to realize that maybe
the operating system should take care of efficient use of the
hardware -- MVS people still refuse to believe that -- so I'm not
surprised.

Careful about what you call "new technology."  Most of the time it's
been out there but you just haven't seen it.  There is absolutely
nothing I've seen in OS/2 that wasn't covered in more detail elsewhere
(you might want to go find some information on MULTICS; you'll learn
something).

Happy hacking,

jim frost
software tool & die
madd@std.com
Technical Details
Message-ID: <1989Nov22.191046.11806@world.std.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!snorkelwacker!spdcc!xylogics!world!madd
References: <1989Nov15.155723.4430@mks.com> <3189@husc6.harvard.edu> <1989Nov21.151129.12991@mks.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!snorkelwacker!spdcc!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.os.os2
Subject: Re: Why is OS/2 a memory hog?
Message-ID: <1989Nov22.191046.11806@world.std.com>
Date: 22 Nov 89 19:10:46 GMT
References: <1989Nov15.155723.4430@mks.com> <3189@husc6.harvard.edu> <1989Nov21.151129.12991@mks.com>
Organization: Software Tool & Die
Lines: 52