Autor Wątek: Message loop pod konsolą?  (Przeczytany 2712 razy)

Offline Karol

  • Użytkownik

# Sierpień 20, 2010, 10:24:09
Szukam informacji o tym jak napisać aplikację pod konsolę linuxa, aby sobie działała, ale nie zżerała całego procesora. Grzebię w google już trzeci dzień i wyczerpałem chyba wszystkie możliwe słowa kluczowe jakie mi do głowy przyszły i nie znalazłem nic.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Liosan

  • Redaktor

# Sierpień 20, 2010, 10:43:06
A na to patrzyłeś: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html ? Pierwszy link z google'a na "linux deamon example",
a jak zjedziesz na sam dół okaże się, że jest tam... while(1) { ....; sleep(30); } ;)

Liosan

# Sierpień 20, 2010, 12:30:05
W niektórych przypadkach można zastosować alternatywe.
np. komenda "crontab" czy "at"
Ale to może nie o to ci chodzi.

Offline t4fun

  • Użytkownik

# Sierpień 20, 2010, 12:55:37
Message loop zazwyczaj występuje przy bibliotekach okienkowych a nie konsolowych.
Aplikacje konsolowe zazwyczaj czekają na interwencję użytkownika, ale zdaje się że chcesz napisać coś co będzie w tle działało. Jeżeli ma to coś dużo liczyć ale nie obciążać mocno procka, to co jakiś czas "sleep" lub "usleep", jeżeli to ma być server jakiejś usługi to polecam zainteresować się funkcją "select"

Offline Karol

  • Użytkownik

# Sierpień 20, 2010, 13:38:06
Ogólnie to ma być program łączący funkcje odtwarzania shoutcasta, kontrolera wyświetlacza LCD i do tego mini serwera http do sterowania tym wszystkim + możliwość reakcji na klawisze (więc nie może to być demon). Czyli rozumiem, że czegoś takiego w konsoli się nie uzyska bez 100% obciążenia CPU (chcę zostawić na procku pasywne chłodzenie i dlatego zależy mi na niskim obciążeniu)? W takim razie jaki menedżer okien jest najmniejszy i najszybszy (chodzi o czas ładowania, a wizualnie może być nawet czarno-biały, bo monitora komputer mieć nie będzie)?

http://karol.infcore.net/2010/05/20/jak-wyglada-wersja-beta/ tutaj jest filmik obrazujący efekt działania takiego programu-serwera, który napisałem pod windowsa, jednak chciałem się na linuxa przerzucić.

Offline Liosan

  • Redaktor

# Sierpień 20, 2010, 13:45:28
Czyli rozumiem, że czegoś takiego w konsoli się nie uzyska bez 100% obciążenia CPU (chcę zostawić na procku pasywne chłodzenie i dlatego zależy mi na niskim obciążeniu)?
To ciekawe, bo żaden post tak nie stwierdził, dwie osoby (w tym ja) podpowiedziały sleepa, i padły jeszcze dwie alternatywne metody oddawania procka.

Liosan

Offline Karol

  • Użytkownik

# Sierpień 20, 2010, 14:14:39
Czyli rozumiem, że czegoś takiego w konsoli się nie uzyska bez 100% obciążenia CPU (chcę zostawić na procku pasywne chłodzenie i dlatego zależy mi na niskim obciążeniu)?
To ciekawe, bo żaden post tak nie stwierdził, dwie osoby (w tym ja) podpowiedziały sleepa, i padły jeszcze dwie alternatywne metody oddawania procka.
crontab odpada, bo musi to być program działający non-stop
sleep/usleep to metoda na około, poda się małe wartości to obciążenie procka wzrośnie, ale jak poda się zbyt duże to program będzie wolniej reagował, w każdym bądź razie zamiast grzecznie czekać sobie na event program co n czasu będzie wałkował w kółko to samo, może 100% to nie będzie, ale i tak więcej niż potrzeba.
select wygląda najsensowniej z całej bandy, ale bez przetestowania mam pewne wątpliwości co do tej metody także

Offline albireo

  • Użytkownik

# Sierpień 20, 2010, 14:37:49
select powinien zadziałać, a jak nie, to sleep powinien wystarczyć, jak będziesz usypiał na milisekundę to czas reakcji będzie wystarczający, a obciążenie w okolicach zera (o ile rzecz jasna po samym sleepie nie będziesz za każdym razem nie wiadomo jakich obliczeń odpalał).

Offline Liosan

  • Redaktor

# Sierpień 20, 2010, 14:46:35
Jeśli masz reagowanie na eventy, to masz całą gamę blokujących wywołań systemowych - czy to czytania z named pipe'a, czy select do czytania z gniazd, czy metody obsługi przerwań, czy co tam chcesz. Wszystko jest 100% skuteczne - na Linuksie ;)

Liosan

Offline BrutalComputer

  • Użytkownik

# Sierpień 20, 2010, 14:49:06
sleep/usleep to metoda na około, poda się małe wartości to obciążenie procka wzrośnie, ale jak poda się zbyt duże to program będzie wolniej reagował
To zrób sobie w pętli
while(1) sleep_milisekundy( 1 );
I zobacz jak wolno ci będzie reagował i jak zabójczo dużo procesora zje.
Mamy obecnie komputery > 3GHz. I to wcale nie jest metoda na około, tylko metoda działająca szybko i dobrze.

Problem by był gdybyś musiał na żądanie odpowiedzieć w określonej liczbie cykli procesora. ( w mikrokontrolerze )

EDIT: Możesz też zobaczyć sockety i pipe
« Ostatnia zmiana: Sierpień 20, 2010, 14:52:05 wysłana przez BrutalComputer »

Offline t4fun

  • Użytkownik

# Sierpień 20, 2010, 14:51:04
Ja po pierwsze podzieliłbym ten program na kilka usług i zrobił między nimi komunikację na unix socketach używając select(), czas reakcji natychmiastowy obciążenie procka bliskie 0%, no chyba że podczas odtwarzania shoutcasta jakieś większe, zależne co jest do dekodowania.
Nie wiem skąd wziąłeś teorię że aplikacja konsolowa jest gorsza od okienkowej pod względem wykorzystania procka.

Offline Karol

  • Użytkownik

# Sierpień 20, 2010, 17:42:23
Mamy obecnie komputery > 3GHz.
Może i mamy, ale mój docelowy sprzęt to 800MHz z drobinką ramu.

Nie wiem skąd wziąłeś teorię że aplikacja konsolowa jest gorsza od okienkowej pod względem wykorzystania procka.
Nic takiego nie powiedziałem, po prostu inaczej się konstruuje program, a po n latach kodzenia pod okienka przywykłem już do nich i ciężko mi teraz przestawić myślenie z zdarzeniowego na proceduralne.

Offline counterClockWise

  • Użytkownik

# Sierpień 20, 2010, 18:24:50
Może i mamy, ale mój docelowy sprzęt to 800MHz z drobinką ramu.

Telefon?

Offline t4fun

  • Użytkownik

# Sierpień 20, 2010, 18:39:47
Mamy obecnie komputery > 3GHz.
Może i mamy, ale mój docelowy sprzęt to 800MHz z drobinką ramu.

Nie wiem skąd wziąłeś teorię że aplikacja konsolowa jest gorsza od okienkowej pod względem wykorzystania procka.
Nic takiego nie powiedziałem, po prostu inaczej się konstruuje program, a po n latach kodzenia pod okienka przywykłem już do nich i ciężko mi teraz przestawić myślenie z zdarzeniowego na proceduralne.

A kto powiedział że musi być proceduralne. Ciągle ci proponujemy funkcję select() powiedzmy że jest taki taki peekMessage, tylko że nie na zdarzeniach podsystemu okien a na zdarzeniach na plikach, w unixach wszytko jest plikiem. Pliki, sockety, czy standardowe wejście są plikami i podpinasz je do select(), proces śpi dopóki nie nadejdzie możliwość czytania/zapisu i dopiero wtedy się budzi. Troszkę pomyśl i masz programowanie zdarzeniowe na którym się znasz.