Fájldescriptorok magtalálása

C/C++

Sziasztok!

Van arra valami API, módszer, ötlet, hogy egy program megtalálja az őbenne nyitva levő összes filédescriptort? Pl. a fork és exec között le kell zárni az összes descriptort kivéve néhány konkrétan megadott darabot, amiket viszont örököltetni kell.

Köszi.

  • 1022 megtekintés

( mrev | 2007. 11. 24., szo – 18:42 )

Nézelődök ilyen helyeken, és nagyon elkeserítő dolgokat látok. Az MS elkezdte deprecateddé tenni a POSIX függvényeket. El vagyok maradva. Francba.

--
CCC3

MS elkezdte deprecateddé tenni a POSIX függvényeket.
cygwin alatt anno (1-2 eve) teszteltem hasonlo progikat, amik sok effele dolgot (fork(), dup/dup2(), exec*(), select(), ...) hasznaltak, azalatt teljesen jol ment minden. ms-e'kne'l a select() is a winsock api-ban mutatkozott be eloszor, jot mosolyogtam ;) szoval az tenyleg messze all a szabvanytol, enyhen szolva.

Ezt használom, de itt nem ismert, hogy milyen fd-k vannak.

Amire gondolok, hogy 0-tól egyesével mindent lezárok, kivéve, ami kell. Kicsit durva, de Linuxon megy.

Na ezért kezdtem nézegetni, hogy mi a helyzet a close-zal úgy általában, mire azt látom az MS-nél, hogy a close deprecated, nem is beszélve a hülye hibakezelésről, aminek az a defaultja, hogy elindítja a Watsont.

--
CCC3

Itt egy link, amiből látszik, hogy másnak is van ilyen problémája. Többszálú program szálai indítgatnak gyerekeket, és nyitogatnak socketeket, pipeokat. Tehát, hogy egy gyerek indításakor éppen mik a nyitott fd-k, az egyáltalán nem egyszerű. Bonyolult szinkronizációra van szükség. Itt hiányosnak látszik a POSIX API.

--
CCC3

Ha feljebb mész a fában, akkor látod, hogy én is gondoltam erre. Két lehetőség volna:

1) fork és exec között mindent lezárni (mint fenn). Ennek még vannak bajai: Windowson nincs ilyen. Ha csak a UNIX-ot nézem, ott is veszélyes (többszálú programban).

2) open/socket/accept/pipe után closeonexecflag, plusz szinkronizálás. Szinkronizálás azért kell, mert az open és a closeonexecflag beállítás között másik szálból gyerek indulhat. Erre írták, hogy kellene egy open_noinherit függvény.

A másodikat választom. Persze a closeonexecflag beállítás is máshogy van Windowson, de az csak kis különbség, nem úgy mint a fork. Na és a child indítás előtt az örököltetni kívánt fd-k closeonexecflagjét ki kell kapcsolni, utána meg vissza.

Köszönöm a segítséget.

--
CCC3

> az open és a closeonexecflag beállítás között másik szálból gyerek indulhat.

Ha a hálózati kapcsolatokat shutdown()-al zárod le, akkor nem számít, hogy egy gyerek örökölte-e a kapcsolatot, vagy sem. Helyi fájlok esetén pedig akkor számít az fd öröklés, ha a gyerek túl sokáig fut, és a nyitva maradt fd-k valami problémát okoznak.

close-zal zárom le.

Nem az kell, hogy a gyerek semmit ne örököljön, hanem azt kell örökölnie, ami az övé, a más gyerekekhez tartozót meg nem. A gyerekek egymást átfedő véletlenszerű időintervallumokban léteznek.

Tényleg nem nagy ügy az se, ha esetleg mindent hagynék örökölni. De nem én fogom írni a gyerekeket, és jobb, ha minél kevesebb galibát tudnak okozni azzal, hogy beleírnak egy véletlenül örökölt nyitott fd-be (amivel elrontják a többiek környezetét).

Lényegében kész van.

--
CCC3

( apal v | 2007. 11. 24., szo – 18:53 )

Linux alatt: /proc/self/fd/*, ezek a megnyitott fileokra mutato symlinkek, mas unix-on pedig (egyeb) specialis fileok (is lehetnek).

fork és exec között le kell zárni az összes descriptort
szerintem inkabb jegyezd meg, hogy kiket nyitottal meg, oszt azokat zard be, ma'rha te irod a teljes programot.

A.