home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8140 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.7 KB  |  65 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!ods!david
  3. From: david@ods.com (David Engel)
  4. Subject: Re: shared libs
  5. Message-ID: <1992Aug13.183740.24742@ods.com>
  6. Organization: Optical Data Systems, Inc.
  7. X-Newsreader: Tin 1.1 PL5
  8. References: <1992Aug12.233349.21513@athena.mit.edu>
  9. Date: Thu, 13 Aug 1992 18:37:40 GMT
  10. Lines: 53
  11.  
  12. Owner of this machine (pmacdona@tadpole.bcsc.gov.bc.ca) wrote:
  13. : At last count, I understood that jump tables do nothing to solve the
  14. : library data problem.  Has that been solved?   If so, just adding
  15. : jump table support to GCC, won't solve the problem.  
  16.  
  17. You're right, a jump table does nothing to solve the data problem.
  18. What I finally did was bite the bullet and change the library source
  19. (there really wasn't that many changes needed) so the relevant data
  20. could be linked at a known location every time.  I also added padding
  21. to leave room for those things that might grow.
  22.  
  23. : First, jump tables have a performance hit.   And using them may
  24.  
  25. Yes, there is a slight performance hit but it's not even noticable
  26. for most programs.  One of these days, when I get the time and 
  27. inclination, I'm going to do some more accurate benchmarking.  The 
  28. 2-4 % I measured a long time ago still seems a little high to me.  
  29. Of course, nobody is forcing you to use the jump table libs.  If you
  30. need that last bit of performance, you can always use the regular 
  31. shared libs.
  32.  
  33. : never work, since the change of one interface will screw the upgrade.
  34. : Worse, if an interface changes without us realizing it, then our 
  35. : programs could just start acting strange (far worse than broken).
  36.  
  37. Yes, an interface change could wreak havoc on the libraries.  However,
  38. in developing version 1 of the jump table libs, I learned several
  39. techniques to handle such changes.  Short of wholesale changes to
  40. the entire library, I think we can handle most changes and retain 
  41. backward compatibility.
  42.  
  43. As someone who has been using the jump table libs almost exclusively
  44. for four months now, I can atest that they are feasible and they do
  45. work.
  46.  
  47. : The current implementation of shared libs has two main characteristics:
  48. : simple and reliable.
  49.  
  50. Make that three:  simple, reliable and a pain in the *ss when it comes
  51. to system maintenance.  You either have to waste disk space by keeping
  52. multiple images of the same library lying around or you have to relink
  53. *everything* whenever library bugs are fixed.
  54.  
  55. : Of course, I would love to be told I am wrong :-)
  56.  
  57. Give them a try when H.J. releases 2.2.2d.  You might be pleasantly
  58. surprised.
  59.  
  60. David
  61. -- 
  62. David Engel                        Optical Data Systems, Inc.
  63. david@ods.com                      1101 E. Arapaho Road
  64. (214) 234-6400                     Richardson, TX  75081
  65.