- This topic has 6 hozzászólás, 5 résztvevő, and was last updated 19 years telt el by
.
-
Bejegyzés
-
Persze ez csak egy kiragadott részlet, de gondolom arról vcan szó, hogy mivel a ebben az esetben a függvények (vagy akár a szál) leállítható egy másik szálból (mellesleg hozzáteszem, hogy a szálak megosztott erõforrásokat is használhatnak), minek következtében az erõforrások nem szabadíthatók fel automatikusan (persze kivételt képez a teljes app. leállítása, ha nem rendszerszintû megosztott erõforrást használ – de manapság ez sem oly gyakori), ezért manuálisan kell… noha megosztott erõforrás esetén figyelni kell.
(Noha a „cancellation”-t nem kötelezõ használni, azaz le lehet tíltani mt esetén… ekkor persze a másik szálból nem lehet leállítani valami „mást” egy másik szálból.)Na, errõl szólna ez + a körítés (gondolom), amit nem idéztél ide…
Kössz!
Akkor már sejtem mirõl van szó! A részlet valóban kiragadott de a funkció leírásában csak itt van szó a multithread -ségrõl.
Gondlom magyarul ez úgy kellene hogy hangozzék, hogy ha a szál ebben a rendszerhívásban „tartózkodik” (mivekl normál esetben ez a funkció arra szolgál hogy a hálózatból érkezet csomagot betolja a megadott pufferbe, ha van, ha nincs áll és Vtovis wrote:Már nem elõször futok bele ebbe a dologba.
NLPT thread – szálat kellene használnom, egy vagy több socket kezeléséhez, visszanézem a „recvfrom” függvényt és a glibc leírásban a következõ angol szöveg szerepel, nem értem„The function is defined as a cancellation point in multi-threaded programs, so one has to be prepared for this and make sure that allocated resources (like memory, files descritpors, semaphores or whatever) are freed even if the thread is canceled.”
Mi akar ez lenni, le kellene állítanom a szálat? – felszabadítva minden hasznnálatban lévõ erõforrást (memória, fájlok stb). Na ne … itt valamit rohadtul félreértek, de mit?
Ugyan nem tudom, hogy kell ilyesmit programozni, de az adott szöveget így fordítanám:
„A függvény többszálú programokban megszakítási pontként van meghatározva, így erre fel kell készülni és biztosítani kell, hogy a lefoglalt erõforrások (mint a memória, leírók, szemaforok és hasonlók) felszabadításra kerülnek a szál megszakításakor is.”
hangos gondolkodás:
Tehát kb úgy kell készülni, hogy mire odaérsz a progiban, ne legyen semmi se lefoglalva, mert adott ponton akár ki is lõheti valaki a szálat.Ez mondjuk lehet, hogy egy hülye példa, de bemutatni jó.
Van egy szálad, mely irányítja a av lejátszó alkalmazás kezelõ felületét… na most elindít egy másik szálat (ez fut az egyik cpu-n*), mely a video folyamot (de)kódolja, egy másik szál (másik cpu-n*) az audiot. Na most, ha a fõszál megkapja a szünet gombot, akkor várakozó állásba kell helyeznie a többi szálat, sõt stop-nál még meg is kell szüntetnie. Ez máskép nem megy, csak, ha a „cancellation” engedélyezett. Hiába zárod be a folyamot, az nem szabadíthatja fel az erõforrásokat… a fõ szálban, elméletileg persze igen, viszont ezt meg a program honnan szívja ki a kisujjából… (hiába is igyekszel itt lefoglalni).„a winsock32 dokujában ilyen kitételek nincsenek”
Attól, hogy „nincsenek”, vannak… (egyébként attól, hogy a mt itt nincs a toppon, azért még tökéletesen lekezelhetõ minden – közvetlenül a cpu használatával -, nem beszélve a kivétel-kezelésrõl, melyek normális használata – pl. 2000 elõtt – csak saját algoritmusokkal valósítható meg. 2000, meg után valamivel jobb a helyzet.)„Tény, hogy én nem szoktam erõszakolt kilõvéseket csinálni”
Ezek (persze) nem erõszakolt kilövések.
Különben nem olyan egyszerû a helyzet.
Egyrészt a task váltásnál a teljes környezet megváltozik, amit tárolni is kell… erre jó tss (task-állapotszegmens). No de ezeket (az egyébként más-más priviligium szinten lévõ task állapotokat) vissza is kell idõrõl idõre állítani, ráadásul figyelni kell, hogy melyik fut… fut-e egyátalán valamelyik, mennyit fut, milyen megosztott és nem megosztott és milyen joggal (rxw) rendelkezõ segmenseket érnek el stb.
Van például egy adatsegmens privilégium szintje 1., akkor mondjuk azt a 0. szinten lévõ kernel, meg mondjuk az 1. szinten lévõ driverek elérhetik, viszont ha a 2. szinten lévõ alkalmazásod (szál akármi) el akarja érni általános védelmi hibát okoz. (Itt például fel sem tudja szabadítani a másik, amíg a kernel például kényelmesen le tudja állítani az alkalmazásodat.) De például, amennyiben a programod egy nem futtatható segmensben jön létre, de ugye a kernel futtani akarja (egy task-állapot mentés után új környezet és ugrás a segmens elejére), az szintén ált. védelmi hibát okoz… na itt jön a kivétel-kezelés.
Valójában ilyen elemekbõl épül fel az egész, csak a magasz szintû nyelvek esetén ebbõl már semmi nem látszik… ami nem is baj addig, amíg valaki meg nem akarja érteni.
Tehát a válszom: ezeket mindenhol be kell tartani, csak az egyik helyen (lib-ben, doksiban) az A + B ill. C mûveletbõl lesz egy X + C, a másikon, meg A + C ill. B. mûveletbõl egy Y + B… Legfeljebb azt mondhatjuk, hogy az X + C hatékonyabb, vagy többet meg lehet vele oldani stb. A maximális rugalmasságot (meg munkát), viiszont az A, B, C adja – ha érted mire gondolok. (A másik lehetõség: lehet mindkettõ akár X + C is, de hiányos doksival.)
Mivel persze nem asm-ben írod a cuccot a segmens rxv, szintek, jó esetben a kivétel-kezelésrõl sem neked kell gondoskodni, de attól még annak a thlibeknek be kell tartaniuk ezeket a szabályokat. 🙂Bocs a wines példálért, de amin most éppen dolgozom az annak a linux -os változata – a wines kiválóan mûködik, még a „gracefull shutdown” is. Jól jönnek az analógiák, egyébként volt nekünk saját, assemblyben írt kernel, csak az még nem ismerte a TCP/IP -t. Az ütemezõ olyanb egyszerû volt amilyet csak ellehetett képzelni, egy sor fölösleg nem volt benne – Z80 -ra írodott.
Ha amennyiben a szál erõforrásait a fõprocessz alatt hozod létre, majd amikor leállítod, akkor ott számolod fel akkor elvileg csak arra kell vigyázni, hogy kivárd amíg a processz kilép. wines világban erre egy egyszerû flaget hasznbáltam amit a fõ processz írt és a szál olvasott – még csak meg sem védtem (criticalsection vagy mutex).
Ami pedig a recvfrom -ot illeti a linuxban az anmûgy is select -el indul, azaz csak akkor aktivizálódik amikor van csomag – nincs várakozás, csomag a pufferba puszi;o)
A többi szállal illetve a fõ processzel már a jól bevált dupla láncolt lista kezelõmet használom, ami mutex -el van védve.Copy-Paste és megvan a fordítás (kicsit gyérül, de érthetõen).
Már nem elõször futok bele ebbe a dologba.
NLPT thread – szálat kellene használnom, egy vagy több socket kezeléséhez, visszanézem a „recvfrom” függvényt és a glibc leírásban a következõ angol szöveg szerepel, nem értem„The function is defined as a cancellation point in multi-threaded programs, so one has to be prepared for this and make sure that allocated resources (like memory, files descritpors, semaphores or whatever) are freed even if the thread is canceled.”
Mi akar ez lenni, le kellene állítanom a szálat? – felszabadítva minden hasznnálatban lévõ erõforrást (memória, fájlok stb). Na ne … itt valamit rohadtul félreértek, de mit?
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz