Princip neutrality říká, že to se knihovny netýká, to by neměla řešit, a zavírání všech deskriptorů při spuštění procesu tak trochu princip neutrality narušuje.
Mohl byste mi přiblížit obsah principu neutrality?
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ě.
Jinak můj názor je, že právě takové použití vaší knihovny ten problém vytváří a nejedná se o problém cizích knihoven. Váš požadavek na otevírání souboru pouze přes vaše API není právě "standardní".
To jste nepochopil. Už v okamžiku, kdy uživatel místo
open použije
std::fstream je tedy nestandardní chování?
(mimochodem, jaké flagy nastavuje STL na své deskriptory???) Požadavek na použití mého API má samozřejmě několik podmínek. Jednak by mělo zjednodušit práci programátora víc, než přímou práci s open/std::fstream a jednak by mělo být multiplatformní, tj, ovládat se stejně minimálně pod oběma mainstreamovýma platformama (windows/linux). Pouze definuju styčné body, kde je třeba občas přecházet mezi mým API a třeba API knihovny třetí strany, například, pokud knihovna vyžaduje FD pro další práci a já mám soubor otevřen v mém objektu představující soubor.
Nicméně smyslem bylo vysvětlit právě ten princip neutrality. Místa, kde dochází k přístupu do mého API se uplatňují jeho (moje) pravidla tak, aby všechny objekty spravované tím API se chovaly konzistentně, tedy, aby deskriptor, který adaptuje moje API byo nesdílený, dokud si uživatel o sdílení explicitně nepožádá. 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.
Navíc to zjednodušuje opt-in. Mohu určit, které deskriptory se budou sdílet a nechat si vygenerovat fake-filename takového deskriptoru. To pak předat na příkazové řádce child procesu, který... pokud je napsán v mé knihovně... může soubor otevřít standardním postupem. Tohle mi totiž bude fungovat i pod Windows (Pomocí DuplicateHandle se zapnutým sdílením).
To, že vám jako autorovi takové knihovny, něco zjednodušuje implementaci knihovny není tak podstatné jako to, že by knihovna měla zjednodušovat práci uživateli takové knihovny.
Myslím si, že to zjednoduší práci i uživatelům. Jak pošlete child aplikaci 5 vstupních a 7 výstupních streamů? Já si je předám na příkazové řádce :-)
Já bych volil ten sysctl, sysconf, nebo getrlimit. Ale to API bych pořádně promyslel.
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.
Průser unixu je zde o tom, že deskriptory se duplikují do cizích procesů a ještě větší průser je, že se duplikují dál do jejich child procesů bez kontroly, protože process, který dál forkuje a provádí exec se vůbec o existenci těchto deskriptorů nemusí dozvědět. Protunelovat se takto do zabezpečené seance tak není žádný problém.
Neutrální postoj je ten, že si to zabezpečím u sebe a nebudu ten průser řešit nějakým hackem a zadělávat si na další průser.