home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8858 < prev    next >
Encoding:
Internet Message Format  |  1992-08-22  |  2.0 KB
  1. Path: sparky!uunet!crdgw1!rpi!newsserver.pixel.kodak.com!laidbak!tellab5!balr!ttd.teradyne.com!news
  2. From: nichols@ttd.teradyne.com
  3. Newsgroups: comp.os.linux
  4. Subject: Re: shared libs - can everyone be happy with this?
  5. Message-ID: <1992Aug21.162841.1@ttd.teradyne.com>
  6. Date: 21 Aug 92 21:24:26 GMT
  7. References: <1992Aug17.144719.1961@crd.ge.com> <1992Aug17.151311.29507@ods.com> <LILJEBER.92Aug17203359@klaava.Helsinki.FI>
  8. Sender: news@ttd.teradyne.com (News Feed Account)
  9. Organization: Teradyne Inc., Telecommunications Division
  10. Lines: 26
  11. Nntp-Posting-Host: mrdata.ttd.teradyne.com
  12.  
  13. In article <LILJEBER.92Aug17203359@klaava.Helsinki.FI>, liljeber@klaava.Helsinki.FI (Mika Pekka Liljeberg) writes:
  14. >> 
  15. >> No, it wouldn't be shareable.  When a process writes to a shared page,
  16. >> it gets its very own copy of it which is no longer shared.  There is a
  17. >> term for this that you probably already know, but others may not.  It's
  18. >> called Copy-On-Write.
  19. > 
  20. > I'll admit right away that I'm no expert, but it seems to me that William is
  21. > right. The page _could_ still be shared, since all the processes using the
  22. > page would be using the same libs. Of course, some kernel support would be
  23. > needed: The page fault handler would have to check, if the referenced address
  24. > is in library space and if so, fix the reference to point to the correct
  25. > place in the library and clear the dirty-bit for that page instead of doing
  26. > a Copy On Write. This would also work for static data references, as long as
  27. > the data structures didn't change too profoundly.
  28. > 
  29. > Would this break demand loading, then? I think not. A text page could still
  30. > be freed and reloaded on demand. Any library references on it would simply
  31. > get relinked, when the path of execution intercepted them.
  32.  
  33. What happens if the 'linker fixup' code just happens to span a text page?
  34. Since it's extremely unlikely that the link code is only one byte long, I
  35. could forsee a problem if only part of it is paged back in ( *BOOM* ).  Try
  36. to find that one with your debugger! :-)
  37.  
  38. Rick
  39.