Co se to spouští? (diskuse)

[David Watzke]

file má obdobu ve formě funkce, nebo ne (libmagic)?

[Luk]

Asi ano. Jen si nejsem jistý, jestli file nedělá o něco víc než jen analýzu podle souboru magic.

[David Watzke]

To asi ne, Googlem jsem našel: "file is now split (thanks to upstream changes) into libmagic and file (as a tiny wrapper executable around the library)"

[Luk]

Pak by bylo skutečně lepší používat knihovnu (libmagic) i v tomto případě.

[happy barney]

knižnice používať v prípade, že daná funkcionalita je nevyhnutná pre správnu funkčnosť programu.

Príklad: web-browser. Môže fungovať aj bez prítomnosti napr gunzip či libz.

Hranica či áno alebo nie, tá je iná ako 1/0.

[Luk]

Samozřejmě nelze spouštění programů zcela zatracovat, u málo využívaných funkcionalit (bez kterých se aplikace obejde) je to v pořádku.

Ale zrovna ZLIB (libz) je příklad toho, kde je zbytečné něco spouštět externě. Je krajně nepravděpodobné, že by v systému byly konzolové utility, ale nebyla tam příslušná sdílená knihovna.

Navíc (k té robustnosti) - při kompilaci lze zjistit, jaké knihovny jsou k dispozici, a když nejsou, tak se příslušná funkcionalita prostě nezakompiluje. A u binárních distribučních balíků se to dá zajistit pomocí závislostí.

Ale znovu opakuji - jde mi hlavně o ty věci, které jsou ve standardních knihovnách (zejména když jsou POSIX-kompatibilní) a jsou tedy k dispozici všude.

[Kníže Ignor]

This program is the "inotify cron" system. It consist of a daemon and a table manipulator. You can use it a similar way as the regular cron. The difference is that the inotify cron handles filesystem events rather than time periods.

LOL. Bezvadně zvolené jméno

[Luk]

Dobré jitro! Pokud jsi trochu sledoval můj blog, tak víš, že na začátku bylo tohle. Takže to jméno jsem v podstatě nevymýšlel, vzniklo jaksi samo.

[Kníže Ignor]

Dobré jitro!

Přesně to jsem měl namysli.

Ostatně nejdůležitější je, že jste s ním spokojen vy

[Luk]

Vzhledem k tomu, že se nejedná o program pro BFU, je tento název velice logický. Asi stejně, jako je logický sám název inotify

[Ladicek]

Rozhodně by se měly vždycky používat knihovní funkce. Pokud neexistují, pak je to chyba návrhu. Přijde mi jako pěkná zhůvěřilost pouštět kvůli nějaké elementární činnosti jiný program a nedej bože pak ještě parsovat jeho výstup.

[wake]

no, zrovna u OOo jde o normalni multithreading, afaik.

[Luk]

To je možné, nezkoumal jsem to, beru to jenom podle toho, co se zaznamenalo do logu. Ale těch zhruba 41-45 spuštění/otevření (nelze rozlišit) kwrite je mi pořádnou záhadou. Tím spíš, že se to stane jen někdy.

[deda.jabko]

btw. jake pouzivate jadro a knihovnu pro praci s vlakny? pod linuxthreads by se kazde vlakno opravdu mohlo hlasit jako spusteni sebe sama...

btw. kdyz aplikace spousti sebe sama tak to nebude zase tak hruza, protoze uz jednou v pameti je takze vetsina veci se nebude nacitat a bude bezet v rezimu copyonwrite.

[Luk]

No, protože používám FC 4-6, je to samozřejmě NPTL (a už hezky dlouho). On někdo dnes ještě používá LinuxThreads?

kdyz aplikace spousti sebe sama tak to nebude zase tak hruza, protoze uz jednou v pameti je takze vetsina veci se nebude nacitat a bude bezet v rezimu copyonwrite.

To sice ano, ale mě to zajímá čistě z principu, proč se tak děje.

[deda.jabko]

ale jiste, stabilni debiani a ze jich je! ted delam jeden projekt, ktery hrube vyuziva vlakna a multiprocessing a kdyz jsem to hodil na test na server se sargem nastacil jsem se divit, jak hrube dokaze propadnout vykon diky linuxthreads. ale za mesic dva tu bude stabilni etch (nebo windows vista ;-]) , takze aj tito mohykani skonci....

[cynik]

Ja se jim vubec nedivim, delam to taky:

*) Pri prekladu daneho programu nemusim mit 150 dalsich knihoven prilinkovanych kvuli jedne funkci, nehlede na to, ze funkce mohou byt v ruznych knihovnach, mit jine parametry atd.

*) Vetsina programku typu rm neni jen obalem nejakeho unlinku, ale umi spoustu veci navic, kterych se da sikovne vyuzit a opet jsou vice nezavisle na prostredi kde se spousti.

*) Navic se tak dosahuje velke robustnosti jednak pri chybach a jednak kdyz nevyhovuje standardni utilitka, napiseme si vlastni a dame ji do cesty aby se hledala driv.

Zkoumal jsem efektivitu tohoto zpusobu volani a rozhodne se na rychlosti nebo pameti projevi jen opravdu malo.. pokud tedy jde o externi programy psane v prekladanem jazyku.

[thingie]

První problém lze obejít tím, že si tu knihovnu nahraju programově. Třetí důvod je celkem to samé jako LD_PRELOAD. No, nevím, nepřijde mi volání externích programů jako nějaké velké zlo. Pokud vůbec.

[xvasek]

Moje řeč. Přidal bych, že voláním externího programu je umožněno míchat 32 a 64 bit kód, možná to jde formulovat i obecněji.

Navíc UNIX byl takto stavěný od začátku a IMHO kvůli této "skládačkovitosti" přežil dodnes. Pokud bych chtěl něco optimalizovat na rychlost, tak má smysl používat knihovní funkce, ale jinak ne. Teď jsem třeba dělal v Perlu nějaký import, který probíhá někde v noci a potřeboval jsem pro string data (datumu) v ISO formátu funkci "o den později". Sáhnul jsem po date a je mi úplně šumák, že se volá v průběhu importu asi 1500krát.

[happy barney]

Hint:

use Class::Date qw(date);

my $o_den_pozdeji = date ('2006-11-08 12:03:00') + '1D';

print $o_den_pozdeji, "\n";

[xvasek]

Dík, za tip. Každopádně my $o_den_pozdeji=`date -I -d $date +1 day` je o jeden řádek a půl hodiny hledání knihovny kratší.

[Jakub Hájek]

Když už se to zde řeší, mohu se zeptat jakým způsobem lze ten externí program zavolat například v C? Dík.

[Luk]

Jsou v zásadě dvě možnosti:

1. system()
2. fork + exec* (execve(), execvp(), execle()...)

První způsob je jednodušší - program se spouští přes shell, stačí předat celou příkazovou řádku jako při interaktivním spouštění. Nevýhodou je jednak právě (zbytečné) spouštění shellu, dále zablokování procesu/vlákna do skončení podřízeného procesu, nemožnost rozumné komunikace s procesem atd.

Druhý způsob je složitější. Prostě se "forkne" (duplikuje) proces a pak se (v potomkovi) zavolá některá z funkcí pro spuštění programu. Původní proces běží dál, může buď čekat na skončení potomka (wait(), waitpid() apod.) nebo zatím něco dělat a občas se podívat, jestli potomek neskončil (příp. reagovat na signál SIGCLD). S podřízeným procesem lze komunikovat přes roury nebo jiným způsobem.

[..]

Lehce poopravim pro ty co by si to chteli hledat: SIGCHLD

[Luk]

Ano, moje chyba, častější (a podle POSIXu) je SIGCHLD, ale SIGCLD lze použít též.

[Jakub Hájek]

Díky, už čtu many těch funkcí. Myslím, že už se konečně pustím do patche pro SIM, aby mi nastavoval away messages pomocí fortunky

[Josef Kufner]

3. popen()

Je to ještě hezčí hračka, když je potřeba přečíst výstup nějakého programu (nebo mu něco předhodit).

[Luk]

No jo, na ten jsem úplně zapomněl. Je někde uprostřed mezi prvním a druhým přístupem (snadná komunikace přes rouru a současně jednodušší práce než přes fork a exec).