egy program mar elinditott peldanyanak vezerlese

 ( hunludvig | 2008. május 7., szerda - 11:08 )

Pelda arra, amit keresek: Sonata zenelejatszo
elinditom: sonata, fut. Kesobb parancssorbol: sonata [play pause stb...]-re a mar elinditott programot manipulalom.
Hogyan lehet ezt szepen elegansan elkesziteni?
DBUS megcsinalja, de szerintem agyuval verebre. illetve a sonata Pythonban irodott, engem meg c/c++ megoldas erdekelne. (mielott vki beirja, hogy "olvasd el!")

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hi!

Anno nekem is pont ilyenre volt szükségem mplayerhez, amihez a popen() függvényt használtam sikeresen. Link .

Ezzel az a gond, hogy egy már futó programot szeretne vezérelni, a popen meg indít egyet...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Jogos, bocsi, ezt benéztem..

Legegyszerűbben signallal lehet jelezni egy programnak.
kill (1) - send a signal to a process
kill (2) - send signal to a process
jelzéskezelő regisztrálás:
sigaction (2) - examine and change a signal action

+1

Egyszer csináltam ilyet. Ha érdekel, akkor személyesen is megmutatom a H57-ben a C++ -os részét. (A többieknek: egy szakra járunk.)

Mit is szeretnél? Processzek közti kommunikációt, azaz Inter-process communication-t. Lásd Wiki.

A D-BUS annyira nem ágyúval verébre, hogy erre van kitalálva.
Előnye, hogy a vezérlést később bármilyen más programból, bármilyen nyelven, könnyen meg lehet oldani.

Amit még használhatsz erre az a Shared Memory, illetve a Socket, de szerintem a D-BUS a legtisztább legszárazabb érzés.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

+ pipe

De, mondjuk ha TCP socketen keresztül oldod meg, akkor távolról is managelhető lesz a progi :)

Ha unix socketen keresztul akkor meg nem, de sokkal jobb, mintha lekillezne a processzt :-)

> de sokkal jobb, mintha lekillezne a processzt

nyilvan ertelmes ember ugy irja meg a progijat, hogy a szamara erdekes megszakitasokat lekezeli. Ebben az esetben nem "lekillezni" fogja, hanem uzenetet kuld neki. Lasd pl. a SIGUSR1 es SIGUSR2 szignalokat, amik kifejezetten ilyesmire vannak "javasolva". De ket program majdnem barmilyen szignal segitsegevel kommunikalhat. Pl. egy daemon-kent (~hatterben) futo progi realisan sosem kap SIGHUP -ot, kovetkezeskent jol hasznalhato bizonyos esemenyek jelzesere. Lasd init, sendmail, bind, inetd, csak hogy az ismertebbeket soroljam.

pipe-ról jut eszembe. mkfifo-val létrehozható egy fifo fájl, amelyet a programból olvasva megkapod azt, amit egy másik program ír a "fájlba". Én eddig csak scriptnél használtam.

Ezt értettem én is pipe alatt.
Van még egy másik változata is amikor nem jön létre állomány a fájlrendszerben, hanem a processzek tudják a fájlleírót, lásd popen(3), pipe(2)

okok :)

> Amit még használhatsz erre az a Shared Memory, illetve a Socket, de szerintem a D-BUS a legtisztább legszárazabb érzés.

Valamint ha mar itt tartunk akkor a Message Queue is erre van kitalalva. Es ellentetben a D-BUS-szal, Unix(-like) rendszerek eseten kategoriakkal hordozhatobb.

Koszonom szepen a valaszokat, szerintem nekem is a kill-es lesz a megoldas.

Vagy megsem a kill az idealis. Process namebol elegge macera visszakapni a process id-t, hogy signalt kuldjek neki. Nem lehetetlen, csak szamomra nem nyujtja a tisztasag erzeset. Atfutom a tobbi javaslatot is. KOszonom oket.

arra olyat szoktak csinálni hogy
/var/run/<progi_neve>.pid
fájlba kiírja induláskor a program a PID-jét

Talan me'g a UNIX domain socket lehet celravezeto", ilyen szigoruan localhost-on futtatott programok vezerlesere. Az XMMS pl igy csinalja (/tmp/xmms_$USER.$SCREEN nev" socket-en), ez nem annyira agyu-vereb.