🚀 go-pugleaf

On 2011-04-18, Piotr B. [pb2004] <p_borkowski@nospamgazeta.pl> wrote:
> Andrzej Rosa <bakters@yahoo.com> wrote:
>
>>> Jakie cuda? Chyba nie uważasz że developerzy Linuksa są głupcami i 
>>> niezmienione strony pamięci z plików które są już na dysku będą drugi 
>>> raz zapisywać w swapie.
>
>> One są w pamięci, nie na dysku.
>
> Doczytaj o demand paging. One znajdą się w pamięci RAM gdy będą 
> potrzebne.

Możliwe, że to też ma znaczenie.  Nie jestem w 100% przekonany,
faktycznie muszę doczytać.

>>  Firefox spawnuje ileś tam child
>> processes o tej samej zawartości, które są w 100% dzielone, stąd
>> rozbieżność.
>
> Mylisz Fxa z Chrome lub IE. 

OK.  Po bliższym przyjrzeniu się, to są oczywiście wątki, nie procesy.

> Poza tym to jest normalne rozwiązanie w 
> każdym systemie. Żaden współczesny system nie duplikuje identycznych 
> stron w pamięci.

Cóż, zawsze twierdziłem że Windows jest przestarzały. ;-P

>>>> Microsoft Windows DLLs are not shared libraries in the Unix sense and do not
>>>> use position independent code. This means they cannot have their routines
>>>> overridden by previously loaded DLLs and require small tricks for sharing
>>>> selected global data. Code has to be relocated after it has been loaded from
>>>> disk, making it potentially non-shareable between processes; sharing mostly
>>>> occurs on disk.
>>>
>>> Powyższe jest bzdurą. 
>
>> Och, to przesada.  Zgodzę się na typowy MS. ;-P
>
> Bzdurą jest to zdanie: Code has to be relocated after it has been loaded 
> from disk, making it potentially non-shareable between processes. 
> Dlaczego pisałem w poprzednim poście.

Z innych powodów, ale realokacja kodu po załadowaniu go do pamięci to
teraz standard.  Facet może mieć rację (a może nie, naprawdę nie jest to
tutaj najistotniejsze).

>>> Wirtualny adres pod jakim jest zamapowana 
>>> biblioteka dll w przestrzeni adresowej danego procesu nie ma nic 
>>> wspólnego ze współdzieleniem pamięci RAM. To system zarządza zawartością 
>>> pamięci RAM i niemożliwe jest aby ten sam plik dll był dwukrotnie 
>>> zamapowany w pamięci RAM jako wykonywalny.
>
>> Nie rozumiesz.
>
>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode
>
>> Position independent code
>
>> First, let it be said that there is no such thing as
>> position-independent code on Windows. The dynamic linker will just
                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> patiently relocate all dynamic libraries that are not loaded at their
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> preferred base address.
   ~~~~~~~~~~~~~~~~~~~~~~~
>
>> Urocze.  :-)
>
> No i? 

No i Windows.  Pełną gębą.

> YPB?

No, nie wiedziałem że w Windowsie murzyn siedzi. ;-)

BTW - preferred base address dotyczy wyłącznie bibliotek systemowych?
No bo nie bardzo sobie wyobrażam, żeby w Redmont wiedzieli gdzie lubi
siedzieć takie libpng. ;-)

-- 
Andrzej Rosa
Working Gentoo flavor:  http://www.funtoo.org
Maintained by Daniel Robbins.