olyat szeretnék, hogy a C fordító elé egy wrappert, ami azt tudja, hogy beledudál egy démonba IPC-n bizonyos feltételek teljesülése esetén, pl. elindult egy CC példány, A démon meg csinál valamit TCP/UDP-n. Cél, hogy a unix szerű rendszerek közül minél többöbön tudjon futni extra ráfordítás/portolás nélkül. Jellemző célplatform a jelentős CC erőforrást használók, *BSD, Linux. OSX nem cél kimondottan, mert nem túl jellemző a tömeges C fordítás.
Felmerült lehetőségek:
C nyelvű démon:
+tömör, lehet binárisban terjeszteni néhány platformra
-relatív lassan lehet fejleszteni benne.
Valmi szkriptnyelv:
+gyorsan lehet haladni vele,
+transzparens, módosítható=többen érdekeltté tehetők
Perl (+ezt tudnám máshol is hasznosítani? -20 éve volt népszerű) vs. Python (+modern, divatos, van jövője)
Magam a szkriptnyelvű megoldások felé hajladozok, de érdekelnek további aspektusok/vélemények.
- 3039 megtekintés
Hozzászólások
Mit szeretnél ezzel elérni? Nem tartom kizártnak, hogy rendelkezésre áll olyan megoldás, melyet építőelemként felhasználhatsz ebben. (Pl. ilyen lehet valamilyen logolás-loggyűjtés és erre épülő automatizáció.)
Szóval, mi a teljes feladat?
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
kell az info, h mikor milyen paraméterekkel lett elindítva egy CC, lehetőleg realtime. tény, hogy ez logolás. Lrgprimitívebb megoldás egy 10 soros shell script, ami a CC helyett meghívódik:
+ legegyszerűbb
+ hamar megvan
- drága a sok sh fork miatt
- networkinget nem tartalmaz
- sh dependant
- A hozzászóláshoz be kell jelentkezni
Én betenném egy wrapper scripttel a helyi syslogba (man logger) és központilag gyűjteném az ilyen eseményeket valami felügyeleti eszközzel.
+legegyszerűbb
+hamar megvan
-erőforrást eszik
+standard megoldás
+network OK
+sh dependency: nem teszünk bele semmi shellfüggőt.
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
Ha ésszel írod meg a saját "cc" parancsodat, akkor minden lehet shell belső parancs, kivéve a valódi cc indítást és a logger-t. Azaz 1 db cc processz helyett 3 (script, logger, cc) fut. Esetleg csinálhatod azt, hogy a scriptben nem direkt hívod a loggert, hanem egy pipe-ba írsz mindent, és azt olvassa egy központi logger - ezzel spórolhatsz némi processzt, de szerintem sokkal jobban elbonyolítod a dolgot.
- A hozzászóláshoz be kell jelentkezni
Ahol "jelentős CC erőforást használók" elemzése a cél, ott ennek a logolásnak az overheadje szerintem nem annyi, hogy foglalkozni kelljen vele.
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
$ cat mycc.sh
echo -- "$@" >> /tmp/pipe
exec realcc "$@"
és egy másik ablakban tail -f /tmp/pipe, vagy ha tényleg hálózatozni akarsz, akkor
logger -p local5.crit -f /tmp/pipe
Nyilván syslog felkonfigurálva, hogy a local5.crit menjen a logszerverre.
Jav: Ha véletlenül a logger nem minden sor elé tenné oda a dátumot, akkor nyilván
echo -- "$( date ) $@"
a megoldás.
- A hozzászóláshoz be kell jelentkezni
köszi.
- A hozzászóláshoz be kell jelentkezni
nem ez a cél. Az a cél, hogy legyen info arról, mennyi ideig futott egy CC szál és milyen paraméterekkel. A "kliensek" elszórva vannak és nem lehet matatni rajtuk, ezért uberlightweight megoldás kell.
- A hozzászóláshoz be kell jelentkezni
Szerintem eredeti formájában nem jó az elgondolásod. Nézz csak meg egy Makefile-t: függőségek vannak bennr leírva, amit a megoldásod nem tudna kezelni. Pl.: ha egy bizonyos wrappelt cc parancs nem készítí el egy (vagy több) .c fájlból a futtatása alatt szinkron módon a .o fájlt, akkor az erre épülő bináris sem linkelhető össze (és akkor még nem esett szó a fordítási hibákról sem).
Ha több gépre szeretnéd elosztani a C fordítási feladatokat, arra ott van például a már kiforrott distcc.
- A hozzászóláshoz be kell jelentkezni
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
python lassabban indul mint a shell, nem javaslom ilyen celra.
golang viszont szoba johet.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni