Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.unix.internals Subject: Re: Fundamental defect of the concept of shared libraries Message-ID: Date: 17 May 91 20:24:39 GMT References: <162@titccy.cc.titech.ac.jp> <7690@auspex.auspex.com> <169@titccy.cc.titech.ac.jp> <7762@auspex.auspex.com> <184@titccy.cc.titech.ac.jp> <1991May16.002617.15386@ladc.bull.com> <197@titccy.cc.titech.ac.jp> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 39 In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 16 May 91 07:07:24 GMT In article <197@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >There may actually not be any "right" implementations extant at the >moment (this is debatable), but that's not the point. Without any fact, your claim is nothing. Neither is yours. If we take 1), the hardware architecture must support PC relative jump, of course. Moreover, to access library private data, it must also address data PC relative. Aside from effeciency, not all architechture support this. Even worse, with some architechture, it is impossible to map several virtual addresses to a physical address. Virtually tagged cache and inverted page tables are notable examples. So some architechtures can't support shared libraries? Well, don't put shared libraries on them. Some architechtures can't support demand paged memory, or virtual address spaces, or preemptive scheduling. Does that mean we have to live without them on machines that can support them? No; it doesn't. I hope you can now understand how complex the shared library is. No, I understand that you aren't qualified to do systems design work. Using your logic, I can show that you can't do any of the things I mentioned above "correctly". They are still usefull in lots of places. The solution is not to "just not do them;" the solution is to understand them and the various implementations, and to know the tradeoffs involved in using those implementatins, and use them where it's appropriate.