—Érdemes-e szerinted egy külön "shared" libet is kreálni, amiben a shared memory kezelésének függvényei vannak benne, vagy ez a core része legyen?
—Hova kerüljön a fork() funkció? ... Netán épp emiatt egyik se legyen a core része, de kerüljenek egyetlen közös libbe? Ha igen mi legyen annak a libnek a neve?
Nem tudom :) Ha a shared memory kezeles logikailag onallo egyseget alkot, akkor lehet ertelme kulon libraryt kesziteni. Ha kizarolag a fork()-al egyutt hasznalando, akkor mehet a ketto egy "process" vagy ilyesmi libbe gondolom, amiben a kulso processek kezelesevel kapcsolatos fuggvenyek vannak. Megindokolhato mindketto miert jo, vagy miert nem jo, vagy hogy miert keruljon a coreba.
Igenám, de van olyan függvényemis ami beolvas egy png képet egy stringbe
png file -> string: "image" lib, amiben a kepfajl kezelessel kapcsolatos fuggvenyek vannak? Vagy ha nem akarod annyira fragmentalni a libeket, akkor "io".
olyan is ami aztán e stringet kiírja a grafikus képernyőre, persze kép formájában
string -> kepernyo: "X" lib, ami a grafikus kepernyot kezeli. Es ennek keszitenek egy inverz fuggvenyt is, ami a "kepernyo -> string"-et intezi.
Meg olyan is van ami egy ilyen "képstringet" kiír egy (png) fájlba.
string -> png file: "image" lib (vagy legalabbis ugyan az, ami beolvas png fajlt)
arra is van funkcióm hogy a grafikus ablak tartalmát elmentsem png képként. Ez most akkor X funkciónak van tekintve vagy png funkciónak?
Mindkettonek, ezert lehet az "X" libben levo kepernyo -> string fuggvenyt hasznalnam hogy egy stringbe rakjam a kepernyo tartalmat, majd pedig az "image" libben levo string -> png file fuggvenyt, hogy kiirjam png fajlba. Ha mindenkepp egy fuggvennyel akarod elintezni, akkor ennek olyan helyen kell lennie, amelyik az "X" es "image" libre is tud hivatkozni.