NetworkManager a __attribute__((cleanup))

27.10.2012 13:01 | Přečteno: 1150× | linux/unix | poslední úprava: 22.12.2012 02:18

Jyrki o problémech s přechodem Archlinuxu na SystemD. Tak si přisadím jednu kontroverzní změnu menšího rozsahu. Spoluvývojáři NetworkManageru by si rádi ušetřili práci začleněním libgsystem, což je víceméně obal okolo __attribute__((cleanup)).

O začlenění prvního ukázkového patche do masteru jsem se dozvěděl tak nějak mezi řečí a protože jsem to považoval za příliš velkou změnu, vydupal jsem si revert na základě předchozí dohody, že se NetworkManager bude vyvíjet o něco více organizovaně a velké změny se budou konzultovat ještě před začleněním.

V tomto případě jsme se chvíli dohadovali o tom, zda je to velká/významná změna či nikoliv. Mým argumentem byla (doufám) nově vzniklá závislost na GCC, což rozhodně není něco, co bych nutně toužil.

Nějaké zdroje k libgsystem a __attribute__((cleanup)):

__attribute__ ((cleanup)), or how I came to love C again

Manuál GCC

Odmítnutí ze strany Glib a GTK+

Pro krátké shrnutí (ale určitě si přečtěte výše uvedené zdroje), __attribute__((cleanup)) umožňuje navázat nějakou akci (uvolnění zdrojů) na okamžik, kdy lokální proměnné končí platnost (například ukončění funkce). Vypadá to jako docela pohodlné vylepšení, nicméně dodělat do programu zpátky ruční uvolňování by dalo docela dost práce.

V tuto chvíli mám ověřeno, že toto rozšíření GCC ve stejné formě funguje i v CLANG (kompilátor pro LLVM). Otázka je, jak naložit s dalšími kompilátory. V tuto chvíli nevím o nikom, kdo by NM běžně kompiloval s něčím jiným než GCC a CLANG vypadá jako nejpravděpodobnější alternativa.

Další projekty, které na tomto rozšíření závisí jsou upstart a systemd, a pravděpodobně se přidají další. To naznačuje, že kompilátor pro linuxový svět tento atribut bude muset tak jako tak implementovat.

Takže, flejmujte, nadávejte, ale hlavně by mě zajímalo těch pár smysluplných, či dokonce odborných názorů na to proč začlenit či proč nezačlenit.

       

Komentáře

[dolik.rce]

Souhlasím s názorem který se objevil u prvního odkazovaného článku - když chce někdo v C používat destruktory a jinak si šetřit práci, měl by zvážit jestli by to neměl spíš psát v C++ nebo nějakém jiném "vysokoúrovňovém" jazyce.

[pavlix]

Toto zvážení už proběhlo. S negativním výsledkem.

[stativ]

Záviset na rozšíření konkrétního kompilátoru mi přijde jako kravina. Krom toho nejsem fanda snah dělat z C něco, co není (aka C++).

[pavlix]

Záviset na rozšíření konkrétního kompilátoru mi přijde jako kravina.

Není to rozšíření konkrétního kompilátoru a nemám zjištěno, zda na nějakých rozšířeních nezávisíme už teď, nebo zda na nich tak jako tak nezávisí některá z našich závislostí :).

Krom toho nejsem fanda snah dělat z C něco, co není (aka C++).

My spíš řešíme, jestli nám to jako vývojářům a projektu pomůže nebo uškodí. Mně osobně z mnoha důvodů C++ nevyhovuje, zatímco tahle funkcionalita by mohla. A nezapomeň, že se bavíš o projektu postaveném nad knihovnou Glib s vlastním objektovým modelem.

[stativ]

Pokud to podporuje jak GCC, tak Clang, tak to portabilitu nijak zvlášť neohrozí (na rovinu – kolik lidí kompiluje NM něčím jiným než GCC nebo Clangem).

Spíš bych koukal po tom, jestli v současnosti jsou nějaké výraznější problémy s uklízením – pokud je tam hodně kódu, který řeší jenom cleanup, nebo nedejbože se častěji objevují bugy způsobené chybějícím cleaupem, tak bych do toho asi šel.

[Petr Tomášek]

Záleží, jak moc je to rozšíření rozšířeno. Asi bych byl v tomto pragmatik...

[Martin Mareš]

Tady je především dobré si rozmyslet, kolik práce použití takového rozšíření ušetří. Teprve pokud se ukaže, že hodně, stojí to za případné problémy s kompatibilitou.

Jsou rozšíření, která mi za to stojí (třeba statement expressions, díky nimž se mi podařilo zavést v libucw velice pohodné funkce pro zacházení s řetězci), zrovna u cleanupů si tím ale vůbec nejsem jistý.

[pavlix]

Tady je především dobré si rozmyslet, kolik práce použití takového rozšíření ušetří. Teprve pokud se ukaže, že hodně, stojí to za případné problémy s kompatibilitou.

Asi dost záleží na stylu práce. My používáme jako utility knihovnu Glib. Hodně věcí se za běhu programu kontroluje na chyby, ale obvykle nejde použít assert, protože je to systémový démon. Spousta chyb přitom vyloženě vyžaduje jen nějaký ladící výstup a ukončení funkce s jasně daným výsledkem (g_return_val_if_fail, g_return_val_if_reached apod). A nebo prosté return.

Něco se dá uklízet pozpátku volanými GOTO, ale v tom se zase dělají chyby.

zrovna u cleanupů si tím ale vůbec nejsem jistý.

NetworkManager je trochu specifický v tom, že většina jeho práce spočívá v komunikaci s dalšími knihovnami či procesy, případně udržuje informace datových stukturách, které si předávají signály.

Takže velká část kódu spočívá v tom, že vyzískám třeba přes libnl od kernelu nějaké objekty, zkontroluju je, a na jejich základě předám další komponentě nějaké další informace.

Colin tvrdí, že jenom na základě alokací může z NM vykopnout 1500 řádků kódu. Mně to v celkovém množství kódu až tak neoslňuje a zda nám to skutečně pomůže, to netuším.

Ale zatím to vypadá, že když to umí i LLVM a když to bude muset umět každý kompilátor s ambicemi kompilovat běžné linuxové služby, tak by se s tím dalo smířit.

[Martin Mareš]

Hodně věcí se za běhu programu kontroluje na chyby, ale obvykle nejde použít assert, protože je to systémový démon.

Opravdu nejde použít? Někdy je nejjednodušší všechen úklid při fatálních chybách zařídit tak, že se příslušná část programu spustí jako samostatný proces a až doběhne, vše se samo uvolní.

Něco se dá uklízet pozpátku volanými GOTO, ale v tom se zase dělají chyby.

Myslíš? Mně naopak konstrukce typu

    bool ok = 0;

    if (!(x = malloc(sizeof(*x)))
        goto failed_malloc;

    if ((fd = open(...)) < 0)
        goto failed_open;

    ok = 1;

    close(fd);
failed_open:
    free(x);
failed_malloc:
    return ok;

přijde jako jedna z nejpřehlednějších možných. Hlavně proto, že je v ní naprosto jasné, kudy program chodí a co kdy alokuje a uvolňuje. Cleanupovací atribut někdy až příliš zamlžuje, v jakém pořadí se věci dějí.

[pavlix]

Opravdu nejde použít? Někdy je nejjednodušší všechen úklid při fatálních chybách zařídit tak, že se příslušná část programu spustí jako samostatný proces a až doběhne, vše se samo uvolní.

Jde o volbu granularity. Abych aplikaci rozdělil tak, aby změna chyb z nefatálních na fatální udělala co nejméně škody, tak by těch procesů mohlo být docela hodně a jejich správa a komunikace s nimi by byla zbytečně náročná.

přijde jako jedna z nejpřehlednějších možných. Hlavně proto, že je v ní naprosto jasné, kudy program chodí a co kdy alokuje a uvolňuje. Cleanupovací atribut někdy až příliš zamlžuje, v jakém pořadí se věci dějí.

Ale jo, já ti rozumím, že chceš všechno vidět jako by to bylo v assembleru :). Ale asi je ti jasné, že nám je pořadí nezávislých dealokací či třeba uvolnění file deskriptorů putna.

[Martin Mareš]

Ale asi je ti jasné, že nám je pořadí nezávislých dealokací či třeba uvolnění file deskriptorů putna.

Jenže ono na tom pořadí tu a tam záleží a když ho popletu, dějí se věci... Proto mi přijde praktičtější pořadí dodržovat vždy a nepřemýšlet nad tím, kdy je to potřeba a kdy ne. Zkrátka alokace a dealokace jsou jako závorky a program by měl být správně uzávorkovaný.

[pavlix]

Jenže ono na tom pořadí tu a tam záleží a když ho popletu, dějí se věci...

Bavíme se stále ještě o pořadí uvolnění několika nezávislých alokací?

Zkrátka alokace a dealokace jsou jako závorky

Tady se asi neshodneme.

[Martin Mareš]

Bavíme se stále ještě o pořadí uvolnění několika nezávislých alokací?

Nikoliv. Bavíme se o uvolňování alokací, aniž by bylo potřeba přemýšlet o tom, zda zrovna jsou nezávislé nebo ne.

V prakticky jakémkoliv větším programu dřív nebo později potkáš alokace, které nezávislé nejsou. Pokud si to o nich neuvědomíš, objeví se dost těžko debugovatelné chyby. Takže alternativy jsou dvě: buďto pokaždé přemýšlet, zda jsou nezávislé (nejen při psaní, ale i při každé budoucí úpravě kódu), nebo si zvyknout dodržovat pořadí všude.

Mně se daleko víc osvědčilo dodržovat pořadí všude, protože je to zjevně správně a myšlenkovou kapacitu si mohu šetřit na ty části programu, které ji skutečně potřebují.

Tohle je nejspíš největší problém programátorů v Céčku: stráví příliš mnoho úsilí ošetřováním všelijakých technických detailů a nezbude jim sil na to hlavní. Dobrý céčkař věnuje úsilí především na to, aby se těmi technickými detaily nemusel zabývat (třeba zavedením nějakých memory poolů, automatického resource trackingu, či třeba transakčního systému, nebo prostě jenom šikovnými konvencemi) a pak už od technikálií má klid na důležité věci.

[pavlix]

Nikoliv. Bavíme se o uvolňování alokací, aniž by bylo potřeba přemýšlet o tom, zda zrovna jsou nezávislé nebo ne.

To pak ano. Ale na to nenarážím, protože uvolňuju objekty a ne kusy paměti, tudíž v případě závislosti už v tuto chvíli, tedy i bez 'cleanup' nevolám free, ale specifickou uvolňovací funkci.

Pokud bych to tak nedělal, což je možná tvůj případ, tak by to opravdu stálo za úvahu.

V prakticky jakémkoliv větším programu dřív nebo později potkáš alokace, které nezávislé nejsou. Pokud si to o nich neuvědomíš, objeví se dost těžko debugovatelné chyby. Takže alternativy jsou dvě: buďto pokaždé přemýšlet, zda jsou nezávislé (nejen při psaní, ale i při každé budoucí úpravě kódu), nebo si zvyknout dodržovat pořadí všude.

V tuto chvíli opravdu pokaždé závislosti řešíme. To by se mělo týkat jak kódu NetworkManageru, tak nejspíš i většiny dalších projektů psaných nad Glib. A přemýšlím nad tím ne ve chvíli, kdy řeším dealokaci, ale už ve chvíli, kdy řeším alokaci.

Mně se daleko víc osvědčilo dodržovat pořadí všude, protože je to zjevně správně a myšlenkovou kapacitu si mohu šetřit na ty části programu, které ji skutečně potřebují.

Chápu. Nicméně nám by to asi nic neušetřilo.

Tohle je nejspíš největší problém programátorů v Céčku: stráví příliš mnoho úsilí ošetřováním všelijakých technických detailů a nezbude jim sil na to hlavní. Dobrý céčkař věnuje úsilí především na to, aby se těmi technickými detaily nemusel zabývat (třeba zavedením nějakých memory poolů, automatického resource trackingu, či třeba transakčního systému, nebo prostě jenom šikovnými konvencemi) a pak už od technikálií má klid na důležité věci.

Tak u nás se z toho důvodu na část věcí používají hotové prostředky z Glib a na většinu ostatních se používají alespoň stejné nebo podobné konvence. Tohle je věc, která přišla rovněž ze světa Glib, ale kvůli nepodpoře na MSVC nebyla zařazena přímo do Glib.

[Tomáš Bžatek]

Sice NetworkManager je freedesktop.org projekt, ale primarne jej pouziva Gnome a to si drzi striktni C89 kompatibilitu. Je to predevsim z historickych duvodu a dnes mozna jiz tyto duvody pominuly, predpokladajic, ze Solaris, OpenBSD a dalsi uz presli na gcc ci clang.

[Petr Tomášek]

predpokladajic

Že ty jsi převlečená Marcela?

[Martin Mareš]

primarne jej pouziva Gnome a to si drzi striktni C89 kompatibilitu

No jo, není od věci se občas podívat na kalendář a zkontrolovat, jaké se píše století

[pavlix]

Něco podobného jsem nadhodil a Dan mi řekl, že něco z c99 používáme a že deklarace máme vždy nazačátku, protože míchání deklarací a kódu je nepřehledné.

[Martin Mareš]

Mně naopak přijde daleko přehlednější deklarovat řídící proměnné cyklů v příkazu for, mimo jiné proto, že je pak evidentní, že na proměnnou nesahám někde mimo cyklus, kde už nemá její hodnota smysl.

[pavlix]

Rovněž souhlasím spíše s tebou. A i v případě, že proměnnou chci používat i po skončení cyklu, dávám přednost deklaraci těsně před (a před ní volný řádek pro optické oddělení.

[pavlix]

Sice NetworkManager je freedesktop.org projekt, ale primarne jej pouziva Gnome

Gnome je jen jedním z projektů, které komunikují s NetworkManagerem.

a to si drzi striktni C89 kompatibilitu.

NetworkManager prý striktní C89 kompatibilitu nedrží, podle toho, co říkal Dan. Možná mi dával i nějaký konkrétní příklad, ale nevzpomínám si.

Je to predevsim z historickych duvodu a dnes mozna jiz tyto duvody pominuly, predpokladajic, ze Solaris, OpenBSD a dalsi uz presli na gcc ci clang.

A jak je to s tím Gnome a případnou závislostí na systemd?

[Tomáš Bžatek]

A jak je to s tím Gnome a případnou závislostí na systemd?

Zatim se o tom dohadujou, neni to jen vec systemd, ale obecne tvrdych zavislosti. Vypada to tak, ze pro zakladni funkcionalitu bude relativne minimum zavislosti a pro tu rozsirenou uz bude potreba systemd. Takze zkompilovat to pujde, ale nebude se jednat o full feature set (coz ja to tak v podstate pouzivam v Gentoo, bez nekterych zbytecnych veci). Diskuze ale stale probiha.

[pavlix]

Zatim se o tom dohadujou, neni to jen vec systemd, ale obecne tvrdych zavislosti. Vypada to tak, ze pro zakladni funkcionalitu bude relativne minimum zavislosti a pro tu rozsirenou uz bude potreba systemd.

To by mě zajímalo, jaké volitelné funkce můžu těžit ze systemd.

[Michal Vyskočil]

Jednak systemd-logind nahrazuje ConsoleKit, čili drobnosti jako zamykání session, uspávání, zakázání logind, aby obsluhoval některé speciální klávesy a podobně.

Stejně tak pro DM je logind nezbytný, takže minimálně gdm, tak i kdm jej používají namísto ConsoleKitu.

No a systemd byl od počátku psán jako univerzální správce "sezení", takže do budoucna i gnome-systemd-session, nebo tak něco, ale to by nejspíše nešlo o volitelnou závislost

[pavlix]

Jednak systemd-logind nahrazuje ConsoleKit, čili drobnosti jako zamykání session, uspávání, zakázání logind, aby obsluhoval některé speciální klávesy a podobně.

Ok, takže z toho máš pak takové XFCE…

Stejně tak pro DM je logind nezbytný, takže minimálně gdm, tak i kdm jej používají namísto ConsoleKitu.

Co si tak pamatuju, tak gdm by mělo predatovat jak systemd, tak consolekit.

No a systemd byl od počátku psán jako univerzální správce "sezení"

Až na to, že ne každý si pod slovem univerzální představuje Linux-only.

[rADOn]

Další projekty, které na tomto rozšíření závisí jsou upstart a systemd, a pravděpodobně se přidají další. To naznačuje, že kompilátor pro linuxový svět tento atribut bude muset tak jako tak implementovat.

Upstart neznam, ale vsadim se ze jako spravna canonicalovina nereflektuje nic za hranicemi LTS ubuntu. Systemd je, bez urazky, ditko stejnych rukou jako pulse audio. To bych nepovazoval za reprezentativni vzorek linuxoveho sveta. To spis samotnej network manager by se za nej dal povazovat.

[pavlix]

To spis samotnej network manager by se za nej dal povazovat.

To mě zajímá :).

[rADOn]

Tak nejak mi pripada ze NM uspesne pronika ruznyma distrama bez toho aby vzbuzoval kontroverze jako vytvory canonicalu nebo poetteringa. Kdyz ho nekdo nepouziva (jako ja tak je to spis tim ze ho nechce nebo nepotrebuje nez ze by delal bordel a zral maly deti.

[pavlix]

Tak nejak mi pripada ze NM uspesne pronika ruznyma distrama bez toho aby vzbuzoval kontroverze jako vytvory canonicalu nebo poetteringa.

Takhle… NetworkManager způsobuje problémy spíše chybami nebo chybějícími funkcemi, než vědomě vtisknutými vlastnostmi. A případné problémy se snažíme řešit. Ale v některých ohledech je jeho použití jako reprezentativního vzorku dosti nelichotivé.