Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!husc6!necntc!linus!philabs!spies!ssdis!gsarff From: gsarff@ssdis.UUCP (gary sarff) Newsgroups: comp.sys.amiga Subject: Re: Amiga UNIX Summary: processes and threads Message-ID: <146@ssdis.UUCP> Date: 27 Jun 88 22:39:49 GMT References: <23602@hi.unm.edu> <4071@cbmvax.UUCP> <142@ssdis.UUCP> <4109@cbmvax.UUCP> Organization: SSDIS-Special Security Department,Internal Security Lines: 34 In article <4109@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <142@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: > >Threads are like shared libraries in the sense that they give you an > >advantage if you have more than 1 process using them. A shared library > Not quite correct: shared libraries are better (in some ways) than > linking into the executable for several reasons: 1) late binding; 2) smaller > executable. Late binding means you can fix routines without having to > re-link/compile the programs, etc. You're right. I was just considering execution benefits though. > > >process or task control block, a stack, a heap, a place to store its > >registers when it is context switched etc, just like a heavy process. Only > >if the process is really executing multiple threads of itself do you get > >any advantage at all. > > This sounds an awful lot like copy-on-write in software. What happens > if one of the threads does an exec()? If one of the threads did an exec you would need some kind of copy-on-write either hardware or software. My point was that I have seen a great many statements like "unix processes are heavy, amiga's processes are light so ours are better". I was just making the point that threads buy you little "lightness" if there is only one process per thread. -- Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff To program is human, to debug is something best left to the gods. "Spitbol?? You program in a language called Spitbol?" The reason computer chips are so small is that computers don't eat much.