POSIX Shared Memory

Schnelle objektorientierte, kompilierende Programmiersprache.
Proxic
Beiträge: 14
Registriert: So Apr 24, 2016 9:38 pm

POSIX Shared Memory

Beitrag von Proxic » Sa Apr 15, 2017 7:32 pm

Ich experimentiere gerade ein wenig mit Shared Memory und bin dabei aber auf ein Problem gestoßen, auf dessen Lösung ich bisher einfach nicht komme. Ich habe auch schon einiges ausprobiert aber zunächst einmal zu meinem Problem:
Ich habe jetzt einen POSIX Shared Memory eingerichtet, um Daten zwischen Prozessen auszutauschen, da ich ein paar Prozesse starte und die dann mit einem exec Aufruf ein seperates Programm ausführen und das ja auch sonst so nicht möglich wäre. In meinem Programm, dass die ganzen Prozesse startet lege ich den Shared Memory an. Dann blende ich den SHM in de aktuellen Prozess ein und speichere darin eine Struktur, in der dann auch die Anzahl der gestarteten Prozesse steht und weitere Infos.

Dann werden die neuen Prozesse mit fork erzeugt aber jetzt kommt mein Problem. Ich würde dann natürlich auch gerne die PID der neuen Prozesse noch im SHM abspeichern. Kann ich denn dann nachher noch an der Stelle in der Struct die Werte manipulieren? In der Struct my_env_t verwende ich nämlich wieder eine Struct, die sich my_proc_t nennt aber leider funktioniert das so gar nicht.

Hier mal ein wenig Code:

Code: Alles auswählen

	int i;
	int fd;
	void *ptr;
	pid_t pid;
	my_env_t my_env;

       // SHM erzeugen und Variablen in my_env speichern
       // ....

	/* now map the shared memory segment in the address space of the process */
	ptr = mmap(0, sizeof(my_env_t), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
	if (ptr == MAP_FAILED) {
		error_routine("mmap() failed\n");
	}

	memcpy(ptr, &my_env, sizeof(my_env_t));
	char *pass_argv[argc + 1]; // + 1 fuer NULL;
	memset(pass_argv, 0, argc);

	pass_argv[0] = argv[2];
	for(i = 1; i < argc; i++) {
		pass_argv[i] = argv[i];
	}
	pass_argv[argc] = NULL;

	for(i = 0; i < num_procs; i++) {
		pid = (int) fork();
		if(pid < 0) {
			error_routine("Fork() error");
		}
		else if(pid == 0) {
			my_env.procs[i].pid = getpid();
			break;
		}
	}

//	ptr += sizeof(my_env_t);
//	memcpy(ptr - ((sizeof(my_proc_t) * my_env.num_of_procs) + sizeof(my_proc_t) * i), &my_env.procs[i], sizeof(my_proc_t));
       memcpy(ptr, &my_env, sizeof(my_env_t));  // Laueft auch so nicht
	if(pid == 0) {
		if(execvp(argv[2], pass_argv) < 0) {
			error_routine(strerror(errno));
		}
	}

        // SHM bereinigen und auf Kinder warten
       // ...
Hier einmal ein Ausschnitt der Strukturen

Code: Alles auswählen

typedef struct {
	int len;
        // ...
} my_msg_t;

typedef struct {
	pid_t pid;
        // ....
	my_msg_t msgs[MAX_MESSAGES_PROC];
} my_proc_t;

typedef struct {
	char *shm_name;
        // ....
	int num_of_procs;
       // ...
	my_proc_t procs[MAX_PROCS];
} my_env_t;
Das was ich auskommentiert habe, also über dem execvp Aufruf funktioniert nämlich so leider nicht. Dann steht nämlich an jedem index des procs Array 0 und nicht der gewünschte pid Wert. Wenn ich einfach vor dem execvp bzw. vor dem if Block

Code: Alles auswählen

memcpy(ptr, &my_env, sizeof(my_env_t));
mache, dann wird das ja von jedem Prozess aufgerufen und die pids in dem procs Array stimmen dann auch nicht mehr oder jeweils nur ein Wert. Wie kriege ich das also hin, dass ich nachher in meinem procs Array die richtigen pids habe?

Aus dem anderen Programm (oder den Prozessen) nachher auf den SHM zuzugreifen oder die Struct my_env funktioniert soweit schon einmal. Da habe ich dann auch den richtigen SHM Namen drinstehen und auch die richtige Anzahl (num_of_procs) drinstehen aber das mit dem procs Array funktioniert nicht richtig. Wie kann ich da also vorgehen?
Das mit der Adressarithmetik funktioniert wie gesagt leider auch nicht, wo ich die Zeilen ptr += habe. Dann steht überall 0 und nicht eine einzige richtige pid. Geht das so mit der struct in der struct nicht und sollte ich das seperieren oder mache ich da bei der Arithmetik was falsch oder gibt es da einen anderen Weg? Ich brauche nämlich die pid's aller gestarteten Prozesse ...

nufan
Wiki-Moderator
Beiträge: 2557
Registriert: Sa Jul 05, 2008 3:21 pm

Re: POSIX Shared Memory

Beitrag von nufan » Mi Apr 19, 2017 10:10 am

Hallo Proxic!
Proxic hat geschrieben:

Code: Alles auswählen

//   ptr += sizeof(my_env_t);
//   memcpy(ptr - ((sizeof(my_proc_t) * my_env.num_of_procs) + sizeof(my_proc_t) * i), &my_env.procs[i], sizeof(my_proc_t));
Von Pointer-Arithmetik innerhalb von Strukturen würde ich dir stark abraten, da du zwischen den Membern teilweise Paddings hast (http://www.catb.org/esr/structure-packing/).
Proxic hat geschrieben:

Code: Alles auswählen

memcpy(ptr, &my_env, sizeof(my_env_t));  // Laueft auch so nicht
Das sieht grundsätzlich gut aus, allerdings wird der Aufruf von allen Child-Prozessen sowie vom Parent-Prozess ausgeführt. Dadurch entsteht eine klassische Race Condition. Nachdem der Parent-Prozess in der Schleife am meisten Arbeit zu erledigen hat, ist es auch nicht unwahrscheinlich, dass er diesen Aufruf als letzter Prozess tätigt und die ursprüngliche Struktur ohne PIDs in den Shared Memory schreibt - und damit alle Schreiboperation der Child-Prozesse überschreibt.

Nachfolgend meine Empfehlung, die - nachdem ich kein vollständiges und testbares Programm habe - eher geraten ist:

Code: Alles auswählen

int index = -1
for(i = 0; i < num_procs; i++) {
    pid = (int) fork();
    if(pid < 0) {
        error_routine("Fork() error");
    }
    else if(pid == 0) {
        my_env.procs[i].pid = getpid();
        index = i;
        break;
    }
}

if (pid == 0)
    memcpy(&(((my_env_t*)ptr)->procs[index]), &(my_env.procs[index]), sizeof(my_proc_t));
Ansonsten würde ich dich bitten einen minimalen aber kompilierbaren Beispielcode zu posten, damit ich auch testen kann.

Proxic
Beiträge: 14
Registriert: So Apr 24, 2016 9:38 pm

Re: POSIX Shared Memory

Beitrag von Proxic » So Apr 23, 2017 1:44 am

Hm .. dass das mit der Pointer-Arithemtik innerhalb der Strukturen nicht gut gehen würde, hatte ich mir auch schon gedacht. Das mit dem padding ist mir auch schon bekannt aber naja, ich bin ein wenig verzweifelt. Dann lasse ich das mal lieber so ganz sein, da ich auch eine struct in einer anderen struct verwende. Ich habe das ganze dann jetzt aufgeteilt und lege die prozesse dann einzeln in dem Shared Memory ab. Das funktioniert aber so immer noch nicht.

Ich habe das ganze oder ehr einen sehr kleinen Ausschnitt zum testen auf ein git repository bei gitlab hochgeladen. Ich wollte hier nicht von jeder Datei alles einzeln posten und so kannst du / ihr euch das direkt herunterladen. Ist natürlich public und ich habe es auch gerade mal augestestet. ;)
Hier kannst du / ihr das finden
https://gitlab.com/Clayman/IPCTest

Mein Ziel ist es jetzt immernoch, die Prozessdaten eines jeden Prozesses (die my_proc struct) in das Shared Memory zu bekommen. Die executable die sich im executable Ordner befindet, soll dann einfach nur die aktuelle Prozessnummer ausgeben aber das funktioniert so gar nicht. Ich bin jetzt auch zwischenzeitlich mal vom Ansatz weggegangen die Prozessdaten direkt bei der Erzeugung in das SHM zu schreiben. Da die Prozesse dann zunächst einmal eine init routine aufrufen sollen, könnte man das ja auch da machen, dachte ich mir. Das könnte man dann in den SHM schreiben aber das funktioniet auch nicht. Das wollte ich mit der IPC_Proc_Init erreichen aber nunja, leider auch nichts. Ich habe den alten Ansatz auch aus meinem Code rausgeschmissen aber der steht ja auch noch hier.

Bei der IPCLib gibt es leider eine kleine Redundanz, da diese in dem executable folder und in dem Projekordner selbst liegt. In dem executable Ordner muss man die leider so immer aktualisieren, wenn man was an der "executable1" ändert. Ich weiß das es auch anders geht aber ich musste das ganze jetzt so zusammenpacken. Die executable soll dann die Datei sein, die ausgeführt wird. Ich habe mit make gearbeitet, also müsst ihr bzw. du dann immer make clean und make machen. Beide Programme haben eine eigene make Datei. Auch das hätte man zusammenlegen könenn aber ich bitte hier deswegen mal um Vergebung. Falls ihr euch nicht mit make auskennen solltet, müsstest du oder ihr das irgendwo importieren. :?
Starten kannst du / ihr das ja dann mit

Code: Alles auswählen

./ipc 5 executables/executable1
und dann sollte der da ja die Ausgaben anzeigen.

Ich hoffe sehr, das du oder jemand anders hier helfen kann. Das zusammenpacken und alles ehr unrelevante rausschmeißen hat mich mehr als eine halbe Stunde gekostet und nunja, wäre echt schade wenn mir keiner helfen kann.

nufan
Wiki-Moderator
Beiträge: 2557
Registriert: Sa Jul 05, 2008 3:21 pm

Re: POSIX Shared Memory

Beitrag von nufan » So Apr 23, 2017 10:14 pm

Mir sind ein paar Probleme in deinem Code aufgefallen:
  • Pointer-Arithmetik mit void-Zeigern ist nicht erlaubt. Wenn du mit Bytes rechnen willst, könntest du z.B. uint8_t* (stdint.h) verwenden.
  • Weiters verwendest du beim anlegen (shm_open) und mappen (mmap) des Shared-Memory falsche Permissions (du setzt alles auf Read-Only, obwohl du schreibst).
  • In executables/IPCLib.c verwendest du env.shm_size als Größenangabe, obwohl dieser Wert nirgends zugewiesen wurde (globale und statische Variablen werden mit 0 initialisiert).
  • Um die PIDs korrekt im Shared-Memory sammeln zu können, musst du die Prozesse davon abhalten, gleichzeitig an die gleiche Stelle zu schreiben. Das kannst du entweder lösen indem - wie in meinem vorigen Posting gezeigt - jeder Prozess einen eindeutigen Index hat oder du Mutexes verewndest um die nächste freie Speicherstelle zu finden.

Proxic
Beiträge: 14
Registriert: So Apr 24, 2016 9:38 pm

Re: POSIX Shared Memory

Beitrag von Proxic » Sa Mai 06, 2017 2:23 am

  • Das Pointer Arithmetik mit void Zeigern nicht erlaubt ist wusste ich ehrlich gesagt nicht einmal aber jetzt wo man sich anschaut warum, macht das auf jeden Fall Sinn. Die warning gab's zwar auch immer aber war mir wie gesagt nicht bekannt.
  • Das mit dem ändern der Permissions ist mir so gar nicht mehr aufgefallen, sitmmte aber auf jeden Fall. Eigentlich dachte ich damals erst, das lesen auch ausreichen würde. Alledings habe ich es dann aber nicht mehr geändert und damit vergessen.
  • Das mit der Größenangabe ist auch so eine Sache aber ich arbeite mich immer noch in die Thematik ein. Ich dachte ja dann eigentlich, dass ich die Größe dann in der Struktur ablege und dann nachher auch benutze aber bevor man sich dann das ganze mit mmap holt, hat man ja noch gar keinen Zugriff darauf und sprich also auch nicht auf die Größe. Das macht also gar keinen Sinn aber naja, irgendwie habe ich nicht daran gedacht. :mrgreen:
    Das mit den pid's habe ich jetzt so mit dem Index gemacht. Man braucht dafür dann ja auch eigentlich nicht unbedingt extra ein mutex sempahor und von daher werde ich es wohl auch nicht verwenden, warum dann auch?
Es läuft jetzt aber endlich. Ich habe dann einfach jeweils auf den enstprechenden Typ gecastet und dann kann man ja auch einfach

Code: Alles auswählen

procs = (my_proc*) (shm + 1); 

machen. Shm zeigt dabei hier auf meine Verwaltungsstruktur und die existiert nur einmal, also + 1 und dann kommen die Prozesse, die ich im SHM abgelegt habe. Das funktioniert auch blendend. Vielen Dank noch einmal für die Denkanstöße.

Eine Frage hätte ich aber auch noch. Ich habe mir jetzt mal die POSIX Semaphoren angeschaut, die man ja auch im SHM ablegen kann und ich will vorher eine (variable) Anzahl an Semaphoren erzeugen. Man muss ja in dem sem_init ein sem_t *sem übergeben.

Ich habe mir dann also ein array von zeigern auf einen ints erstellt und wollte die dann alle entsprechend in einer Schleife (eigentlich Funktion) initialisieren. Das sieht jetzt zurzeit so bei mir aus und es funktioniert auch

Code: Alles auswählen

int j;
sem_t *sems[num_of_sems];
for(j = 0; j < num_of_sems; j++) {
	sem_init((&sems[j]), 1, 0);
}
passing argument 1 of ‘sem_init’ from incompatible pointer type [enabled by default]
aber leider nicht ohne warnings.
Ich strauchle aber auch immer noch so ein wenig, wenn es um Pointer geht, vor allem in Verbindung mit arrays. Warum kriege ich da noch die Warning? Wenn ich dann vorher noch caste, also so

Code: Alles auswählen

sem_init(((sem_t*)(&sems[j])), 1, 0);
D`dann kriege ich zwar keine warning mehr aber muss man da wirklich so noch explizit casten? Ich wollte das ganze auch eigentlich (wie oben schon geschrieben) in einer Funktion initialisieren aber dann kriege ich einen Speicherzugriffsfehler.

Code: Alles auswählen

void init_semaphores(sem_t ***sems[]) 
Das meine ich aber auch mit straucheln. Ich will ja eigentlich ein array in die Funktion reingeben und wenn ich nachher aus der Funktion zurückkehre, dann soll das array initialisiert werden und dann will ich das anschließend im SHM ablegen. Das obige Beispiel war jetzt so direkt ohne Funktinsaufruf. Mit funktioniert gar nicht.

Code: Alles auswählen

void init_semaphores(sem_t *sems[]) {
	int j;
	for(j = 0; j < num_of_sems; j++) {
		sem_init((&sems[j]), 1, 0);
	}
}
aber wie muss ich ein array von zeigern auf einen int übergeben und dann nachher auch richtig in der Funktion oben benutzen? sem_init will ja einen Zeiger auf eine Speicheradresse haben und nicht den Wert. Könnte mich da jemand aufklären? :?: :shock:

nufan
Wiki-Moderator
Beiträge: 2557
Registriert: Sa Jul 05, 2008 3:21 pm

Re: POSIX Shared Memory

Beitrag von nufan » Sa Mai 06, 2017 9:35 pm

Proxic hat geschrieben:Eine Frage hätte ich aber auch noch. Ich habe mir jetzt mal die POSIX Semaphoren angeschaut, die man ja auch im SHM ablegen kann und ich will vorher eine (variable) Anzahl an Semaphoren erzeugen. Man muss ja in dem sem_init ein sem_t *sem übergeben.
Warum willst du diese im Shared Memory ablegen? Und wozu genau brauchst du mehrere davon? Meinst du das unabhängig vom vorherigen Ziel, die Prozess-Informationen in den Shared Memory zu schreiben?
Vielleicht siehst du dir mal dieses Beispiel mal an:
https://gist.github.com/tausen/4261887
Proxic hat geschrieben:Ich habe mir dann also ein array von zeigern auf einen ints erstellt und wollte die dann alle entsprechend in einer Schleife (eigentlich Funktion) initialisieren. Das sieht jetzt zurzeit so bei mir aus und es funktioniert auch

Code: Alles auswählen

int j;
sem_t *sems[num_of_sems];
for(j = 0; j < num_of_sems; j++) {
   sem_init((&sems[j]), 1, 0);
}
sem_init() erwartet sich einen Zeiger auf ein sem_t. Syntaktisch korrekt wäre also folgendes:

Code: Alles auswählen

sem_init(sems[j], 1, 0);
Somit passt dein Parameter zur Signatur. Allerdings befindet sich an der übergebenen Adresse keine gültige Instanz von sem_t - du hast sie ja nirgends angelegt oder mit malloc() Speicher dafür reserviert. Du hast Zeiger ins nirgendwo und dort schreibt sem_init() dann entsprechend auch hin. Der Segmentation Fault ist die logische Folge daraus.

Du kannst sem_t-Elemente einfach als Array anlegen und dann über den Adressoperator die Adresse abfragen:

Code: Alles auswählen

int j;
sem_t sems[num_of_sems];
for(j = 0; j < num_of_sems; j++) {
   sem_init(&sems[j], 1, 0);
}
Wobei ich nach wie vor skeptisch bin, ob du wirklich eine dynamische Anzahl davon haben willst, vielleicht überdenkst du diesen Ansatz nochmal. Oder erklärst genau was du erreichen willst ;)

Proxic
Beiträge: 14
Registriert: So Apr 24, 2016 9:38 pm

Re: POSIX Shared Memory

Beitrag von Proxic » So Mai 14, 2017 5:51 pm

Ich lege die Semaphoren im SHM ab, weil ja alle Prozese darauf nachher einfach darauf Zugriff haben sollen. Man könnte warscheinlich auch einfach Named Semaphore benutzen aber das ist ja eigentlich nicht wirklich notwendig. Eine dynamische Anzahl brauche ich übrigens auch, weil ich ja auch eine variable Anzahl von Prozessen starte und jeder Prozess eine maximale Anzahl an Nachrichten haben darf und es auch ein Gesamtlimit gibt und man kann ja nicht ein Semaphor für 10 Prozesse benutzen. Da brauche ich schon eine dynamische Anzahl.

Das "witzige" ist, dass ich den Fehler echt kurz vor deinem Posting hier gefunden habe und das ist leider sehr oft bei mir so. Das hat mich auch ein wenig geärgert aber naja, so ist das oft bei mir. Manchmal fällt mir die Lösung auch während des schreibens ein aber naja, wenn man über sein Problem etwas schreibt, muss man sich ja auch noch einmal damit auseinadersetzen und das scheint mir wohl öfter mal die Augen zu öffnen. :oops:

Jetzt habe ich aber auch wieder einen Fehler, der mich gerade absolut blockiert, und zwar habe ich ja jetzt Semaphore und Nachrichten hinzugefügt aber jetzt kommt es beim ablegen der Nachrichten in's SHM zu einem Segmentation Fault (Speicherzugriffsfehler) und zwar konkret hier im Starter:

Code: Alles auswählen

for(i = 0; i < msg_count; i++) {
	init_msg(&msgs[i]);
	fprintf(stderr, "memcpy for msgs[%d]\n", i);
	memcpy(msg, &(msgs[i]), sizeof(my_msg));
	msg += 1;
}
Ich dachte erst, dass der Fehler ein out of bounds Fehler beim Array wäre aber das scheint nicht das Problem zu sein, sondern die Speicheradresse msg. Ich habe auch schon einmal versucht, den Speicherbereich des SHM drastisch zu erhöhen aber immer noch derselbe Fehler. :?:
Mache ich irgendwo einen Fehler beim Berechnen der Größe des SHM oder ist da doch was mit dem Array nicht in Ordnung? Jetzt abe ich echt keine Ahnung und nicht wie vorher, wo man noch einmal denkt "ach, vielleicht liegt es ja hier oder da dran ... ".

ich habe das Projekt im gitlab repository jetzt auch einmal auf den dahingehenden Stand gebracht aber noch nicht die Extraktion der Semaphoren und der Nachrichten aus dem SHM in der IPCLib Datei aber es kommt ja auch zu dem Fehler in dem Starter. Hier habe ich aber jetzt, wie gesagt leider gar keinen Lösungsansatz.
https://gitlab.com/Clayman/IPCTest

nufan
Wiki-Moderator
Beiträge: 2557
Registriert: Sa Jul 05, 2008 3:21 pm

Re: POSIX Shared Memory

Beitrag von nufan » So Mai 14, 2017 7:33 pm

Proxic hat geschrieben:

Code: Alles auswählen

ptr = (my_env*) mmap(NULL, sizeof(env.shm_size), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Da gehört kein sizeof() hin.

Proxic
Beiträge: 14
Registriert: So Apr 24, 2016 9:38 pm

Re: POSIX Shared Memory

Beitrag von Proxic » Do Jun 15, 2017 12:40 am

Hi, den Fehler hätte ich glaube ich noch eine Zeit lang gesucht aber das werde ich mir auf jeden Fall noch einmal merken, da noch einmal alles in Zukunft nachzuprüfen oder bei einem Fehler auch noch einmal die Funktionsparamter zu prüfen aber vorher war das sizeof auch mal richtig. Nur habe ich dann vergessen es später zu entfernen. :oops:
Ohne deine Hilfe hätte ich da bestimmt noch einiges an Zeit geopfert.

Leider stecke ich jetzt wieder an einer alten Stelle fest, nämlich da wo mit fork die Prozesse erzeugt werden. Jetzt wollte ich es nämlich so machen, dass die erzeugten Prozesse ein Programm starten (oder auch unterschiedliche aber egal) und mein for-Block, wo die Prozese erzeugt werden sieht dann jetzt dementsprechend so aus:

Code: Alles auswählen

for(i = 0; i < num_of_procs; i++) {
	pid = (int) fork();
	if(pid < 0) {
		return 0;
	}
	else if(pid == 0) {
		sem_wait(&sem[0]);
		execvp(argv[2], passed_argv);
		error_quit("execvp() failed");
	}
	else if(pid > 0) {
		procs[i].pid = pid;
		// Weitere Daten
	}
}

memcpy(proc, procs, sizeof(my_proc) * num_of_procs); // Alle Prozesse auf einmal in den SHM

// wake up childs
for(i = 0; i < num_of_procs + 1; i++) {
	sem_post(&sem[0]);
}
Da die Prozesse dann ja das Programm verlassen oder ich bei einem fehlerhaftem execvp-Aufruf den Prozess (oder das Programm) beende und die Prozesse nachher alle auf den SHM zugreifen, warte ich erst, bis der Starter und die Prozese ihre Daten (pid etc.) in den SHM ablegen. Es kann ja sonst auch passieren, dass ein Prozess mit einem noch nicht initialisiertem Prozess kommuniziert, also der seine initialen Daten noch nicht einmal im SHM abgelegt hat, gerade wenn es sehr viele Prozesse werden. (Proc ist ein ptr auf den Speicherbereich im SHM, wo die Prozessdaten abgelegt werden sollen und procs ein Array von Prozessen. sem[0] ist eine zählende Semaphore, die ich mit 0 initialisere und auch als shared

Code: Alles auswählen

if(sem_init(&sem[0], 1, 0) != 0) {
	return 0;
}
und die dann einfach nachher, nachdem der Elternprozess alle Daten im SHM abgelegt hat, alle childs wecken soll.
Jetzt passisert es aber irgendwie, dass wenn ich mehrere Prozesse starte, die Schleife mehrere Male (vor alelm später im Programmablauf) durchzulaufen scheint, aber immer mit 0 anfangend (sich wiederholt?) und das obwohl die Prozesse ja dann ein neues Programm laden?! Es scheint bald irgendwie so, als wenn die Prozesse doch zurückkehren aber das kann ja nicht?! Dann läuft die Schleife nämlich noch einmal von 0 bis n durch (n = Anzahl Prozesse).

Die erzeugten Prozesse laufen dann ja in den else if(pid == 0) Zweig und warten dann und der Elternprozess initialisiert dann ja die Daten, da der Elternprozess dann ja immer für jeden Prozess in den else if(pid > 0) Zweig läuft und das sollte doch so klappen? Naja, irgenwie leider nicht ...
Ich verstehe nicht, wie das kommt und bitte daher noch einmal hier um Hilfe.

Danke schon eimmal im voraus!

Proxic
Beiträge: 14
Registriert: So Apr 24, 2016 9:38 pm

Re: POSIX Shared Memory

Beitrag von Proxic » Fr Jun 16, 2017 2:10 am

Hm .. ich habe auch mal alles, inklusive dem senden und empfangen der Nachrichten etc. auf ein neues repository gepusht. Der tests_src Ordner sollte aber über dem IPC Ordner legen, da sonst make einen Fehler wirft und ich das auch so eingerichtet hat und man sonst zwei main's in einem Ordner hat und mit vielen Entwicklungsumgebungen so nicht arbeiten kann, wie bspw. Eclipse. Jetzt kompiliert auch alles automatisch, wenn man die make im IPC Ordner startet, nur mal so als Anmerkung (sehr viel komfortabler).

Wenn du oder jemand anders den ipc_sendrecv_max_procs startet, mit mehr als 50 Prozessen, dann sieht man den Fehler. Wenn man aber nur weniger oder gleich 30 startet, läuft noch alles ohne Probleme. Ich denke, wie gesagt das er bei dem forken liegt aber ich kann mich auch irren.

Hier mal der Link zum Repo:
https://gitlab.com/Clayman/IPC

Antworten