библиотека адресного пространства или процесс

Question

У меня есть одно основное сомнение.У меня есть процесс, который использует общую библиотеку.Если я выделяю некоторую память в библиотеке, то какое это адресное пространство.(Библиотека или процесс) По моему мнению, это адресное пространство процесса, потому что после присоединения библиотеки все находится в адресном пространстве процесса.

Пожалуйста, исправьте меня, если я ошибаюсь.

Спасибо Arpit

Answer 1

Библиотека не имеет собственного адресного пространства.Он отображается и выполняется в каком-то процессе.Значит ты прав.Выделение памяти разделяемой библиотеки выполняется внутри процесса, который ее использует.

Answer 2

Похоже, что вы, возможно, путаетесь между адресным пространством и кучей.

Процесс имеет одно адресное пространство и все внутри процесса (основной исполняемый файл, любые общие библиотеки и любые статические библиотеки)все они используют одно адресное пространство.

Хотя в одном адресном пространстве может быть несколько куч, glibc реализован таким образом, что существует только одна стандартная куча (под стандартной кучей я имею в видуодин вы получаете доступ через malloc / free).Это отличается от Windows, где исполняемый файл и DLL могут иметь свою собственную кучу (хотя, опять же, общий ресурс одного адресного пространства).

Answer 3

Библиотека не имеет места в памяти сама по себе, так как это не запущенный процесс.Концепция общей библиотеки состоит в том, чтобы иметь общую копию инструкций кода, но не каких-либо данных, используемых или генерируемых этим кодом.

, например, если ваша библиотека предназначена для управления динамически распределенной структурой:

object.h

 struct object_struct {
        char *name; 
        int foo;
        int bar;
 };

 typedef struct object_struct * object_t; /* opaque pointer */

 object_t new_object (char *name, int foo, int bar);
 void delete_object(object_t);
 int dump_object(object_t);

object.c

  #include <stdio.h>
  #include "object.h"    

  object_t new_object (char *_name, int foo, int bar) {
       object_t _p = malloc(sizeof(object_t);
       if (!_p) 
             return NULL;
       _p->foo = foo; _p->bar = bar;
       _p->name = strdup(_name);
       return _p;
  } 

  void delete_object(object_t p) {
       if(_p->name) 
          free(_p->name);

       if(_p) 
           free(_p);
  }

  int dump_object(object_t p) {
       FILE * fp = fopen(p->name, "w");
       if ( !fp ) 
            return -1;
       fprintf(fp, "foo: %d\nbar: %d\n", p->foo, p->bar);
       fclose(fp);
       return 0;
  }

И у вас есть две программы consumer1.c и consumer2.c, которые используют этот объект библиотеки, как показано ниже:

consumer1.c

 #include "object.h"

 int main() {
      object_t o = new_object("consumer1.txt", 1, 2);
      dump_object(o);
      delete_object(o);
      return 0;
 }

consumer2.c

 #include "object.h"

 int main() {
      object_t o = new_object("consumer2.txt", 1, 2);
      dump_object(o);
      delete_object(o);
      return 0;
 }

для всех намерений и целей, эти две программы библиотеки объектов НЕ БУДУТ иметь общих данных или общей памяти или общего пространства.

PS: при условии, что gcc и gnu make, вот файл make для васпроверить все это.

Makefile

default: libobject.a consumer1 consumer2

.c.o: %.c
    $(CC) -c -o $@ $<

libobject.a: object.o
    $(AR) r $@ object.o


object.o: object.c object.h

consumer1 consumer2: $@.o libobject.a
    $(CC) -o $@ $@.o -L. -lobject 

PPS: это просто руководство!Я не проверял код здесь ВСЕ, надеюсь, он все работает без проблем, однако, возьмите его с крошечным солью, и если я допустил синтаксическую ошибку, пожалуйста, исправьте соответствующим образом.

Answer 4

Общая библиотека может связываться со многими процессами, и она запускается в контексте этих процессов.

Допустим, у вас есть общая библиотека для отправки http-запроса. Процесс браузера и настольное приложение могут связываться с этой библиотекой, но контекст процесса позволит им отправлять независимые запросы, несмотря на то, что оба загрузили одну и ту же библиотеку.

Следовательно, контекст процесса определяет распределение памяти независимо от того, где она написана (процесс или библиотека).