Laicky řečeno, nepletu se do věcí, do kterých mi nic není. Zavřením všech deskriptorů při spuštění jiného procesu bych zasáhl do obvyklých zvyklostí programů třetích stran, které třeba mají důvod, proč mají sdílení zapnuté. Nechci prostě opravovat "průser" unixového API, chovám se k němu neutrálně.
To není pravda. Jednak se o průser nejedná a za další do ničeho nezasahujete, pokud chcete provádět věci dle předchozího příkladu. Naopak neřešíte běžné situace.
Spíš mi přijde, že jste odkojen win32 (pletu se?) a tak vám některé věci z linuxu nesednou. Já ale žádný problém nevidím, protože jsem zvyklý na fork a jeho vlastnosti.
Už v okamžiku, kdy uživatel místo open použije std::fstream je tedy nestandardní chování?
Nestandardní je podmiňovat použití knihovny změnou přístupu k API OS. Jistě existují vyjimky (paměťový management apod.), ale běžné to není. Navíc to stále neřeší případy, kdy proces obsahuje deskriptor(y), které uživatel explicitně neotevřel. Takže stejně se o jejich uzavření (pokud je chce uzavřít) musí postarat sám. Tak kde je ta výhoda std::fstream?
(mimochodem, jaké flagy nastavuje STL na své deskriptory???)
Nevím, ale nečekal bych nějakou spásu. Mrkněte se do zdrojáků.
Deskriptory, které si vytvoří knihovna třetí strany v rámci své práce a nevstupují do mého API mi jsou naprosto volné. Není moje zodpovědnost žehlit chyby v knihovnách třetích stran a pokud knihovna interně vytváří deskriptory, které se by default sdílí, je to problém knihovny a programátora, který tu knihovnu používá. Má knihovna neumí rozhodnout, zda je to záměr, nebo chyba.
Opakuji. Nejde o chybu knihoven třetích stran. Knihovna nemá a nemůže mít nejmenší tušení, že vy děláte poměrně radikální manipulaci s procesem (fork, execve).
Jde o chybu vaší knihovny, že se nechová ke zdrojům procesu konzistentně a tudíž korektně (část deskriptorů zavíráte a část ne). Vy vytváříte proces, vy jste zodpovědný za vyřešení problémů, kterou jsou s tím spojené. A to navíc tak, aby to práci uživateli ušetřilo.
V tuto chvíli není jediný důvod, aby používal vaši fstream. Ani jeden důvod. O obsluhu ostatních deskriptorů se musí postarat tak, jako tak, takže k čemu by si měl komplikovat život?
Jak pošlete child aplikaci 5 vstupních a 7 výstupních streamů? Já si je předám na příkazové řádce :-)
Když pominu, že můžete předat (v unixu) jen čísla deskriptorů a nikoli streamy, tak to záleží na té aplikaci, jaké si k tomu definuje API. Předat pár čísel lze různými způsoby (příkazová řádka, fixní čísla deskriptorů, přes reálný, přes stdin/out, příp. další IPC prostředky)
Já bych volil ten sysctl, sysconf, nebo getrlimit.
Mě to přijde jako hackoidní řešení. Chápu to u sshčka, i když tam se taky bere jen prvních 64 deskriptorů, pak se člověk ptá, zda to vůbec má smysl.
Ať už se vám to zdá jakékoli, projití té tabulky je v současné době jediné řešení. Ve fbsd by šlo ještě použít kombinaci duplikace deskriptorů a closefrom.
Průser unixu je zde o tom, že deskriptory se duplikují do cizích procesů a ještě větší průser
Má Anglie průser v tom, že jezdí na levé straně? To je jako tvrdit, že průser windows je v tom, že nový proces nelze udělat bez souboru na FS. Jedná se prostě o 2 různé přístupy a oba mají + a -.
Tohle (v)fork API tu je přes 30 let. Ukažte mi ten průser v praxi.
13 Odpovědí
4393 Zhlédnutí