abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 22:00 | Komunita

Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil (podcast) detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 64 tisíc vývojářů. Jejich nejmilovanější platformou je linuxový desktop. Ten je také druhou nejpoužívanější platformou vývojářů.

Ladislav Hagara | Komentářů: 0
včera 11:55 | Komunita

Vývojový tým OpenSSL ve spolupráci s iniciativou Core Infrastructure konsorcia Linux Foundation spustil proces přelicencování této kryptografické knihovny ze současné licence na licenci Apache Licence v 2.0 (ASLv2). Nová licence usnadní začleňování OpenSSL do dalších svobodných a open source projektů. Všichni dosavadní vývojáři OpenSSL (Authors) obdrží v následujících dnech email s prosbou o souhlas se změnou licence.

Ladislav Hagara | Komentářů: 7
včera 01:11 | Komunita

Před třemi týdny Mozilla.cz představila projekt Photon, jehož cílem je návrh a implementace nového vzhledu Firefoxu. Včera zveřejnila první náhled vzhledu Photon. Práce na projektu Photon jsou rozděleny do pěti týmů, které celkem čítají 19 lidí. Zaměřují se na zlepšení prvního spuštění Firefoxu a zaujetí nových uživatelů, celkovou úpravu vzhledu, zlepšení animací, zrychlení odezvy uživatelského rozhraní a také upravení nabídek. Vývoj lze sledovat v Bugzille.

Ladislav Hagara | Komentářů: 36
23.3. 20:00 | Komunita

OneDrive pro firmy je již ve webových prohlížečích na Linuxu stejně rychlý jako na Windows. Microsoft opravil chybu z listopadu loňského roku. OneDrive pro firmy běžel na Linuxu mnohem pomaleji než na Windows. V popisu chyby bylo uvedeno, že stačilo v prohlížeči na Linuxu nastavit v user-agentu Windows a vše se zrychlilo. Odpovědí Microsoftu bylo (Internet Archive: Wayback Machine), že Linux není podporován. Po bouřlivých diskusích na redditu i Hacker News byla chyba nalezena a opravena.

Ladislav Hagara | Komentářů: 6
23.3. 19:00 | Zajímavý projekt

Byla vyhlášena soutěž Hackaday Prize 2017. Soutěž je určena vývojářům open source hardwaru. Pro výherce je připraveno celkově 250 tisíc dolarů. Každý ze 120 finalistů získá tisíc dolarů. Nejlepší pak navíc 50, 30, 20, 15, 10 a 5 tisíc dolarů. Jedná se již o čtvrtý ročník soutěže. V roce 2014 zvítězil projekt globální sítě open source pozemních satelitních stanic SatNOGS. V roce 2015 zvítězil open source systém pro řízení elektrických invalidních vozíků pohybem očí Eyedriveomatic. V roce 2016 zvítězil modulární robot Dtto.

Ladislav Hagara | Komentářů: 0
23.3. 15:00 | Bezpečnostní upozornění

Byla vydána Samba ve verzích 4.6.1, 4.5.7 a 4.4.12. Řešen je bezpečnostní problém CVE-2017-2619. Pomocí symbolických odkazů a souběhu (symlink race) lze "teoreticky" získat přístup k souborům, které nejsou sdíleny. Linuxové distribuce jsou postupně aktualizovány (Debian).

Ladislav Hagara | Komentářů: 0
23.3. 07:43 | Nová verze

Na Steamu se objevil port hry Arma: Cold War Assault (Operation Flashpoint) pro Mac a Linux. … více »

creon | Komentářů: 30
23.3. 05:55 | Nová verze

Po 18 měsících od vydání verze 8.0 byla vydána verze 9.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
23.3. 03:33 | Komunita

Platnost posledního patentu souvisejícího s Dolby Digital (AC-3) vypršela. Po MP3 se tak do Fedory oficiálně dostane také kodek AC-3.

Ladislav Hagara | Komentářů: 5
23.3. 00:44 | Komunita

Feral Interactive, společnost zabývající se vydáváním počítačových her pro operační systémy macOS a Linux, nabízí své hry na Steamu vývojářům open source 3D grafické knihovny Mesa zdarma. Podmínkou je minimálně 25 commitů za posledních 5 let. Stejnou nabídku dostali vývojáři knihovny Mesa v roce 2015 od Valve. O rok dříve dostali od Valve tuto nabídku vývojáři Debianu a Ubuntu.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 931 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Způsoby komunikace dvou běžících aplikací

    24.3.2014 16:55 gld17 | skóre: 4 | blog: GLDiuv_blog
    Způsoby komunikace dvou běžících aplikací
    Přečteno: 717×
    Dobrý den,

    stavím si quadcopteru s Raspberry Pi. Mám servrovskou aplikaci běžící na mém notebooku a klientskou aplikaci běžící na Raspberry (s Raspianem (Debianem)).

    Klientskou aplikaci mám napsanou v javě. Potřebuji však komunikovat s modulem MPU6050 (akcel.+gyro) připojeným přes I2C.

    Pro MPU6050 existuje jediná napsaná knihovna, která umí plně využít jeho možnosti (MPU6050 umí totiž provádět výpočty přímo v sobě). Tato knihovna je napsaná v C++ a nedovedu si představit jí přepisovat do javy.

    Chci se proto zeptat linuxáků, co by mi poradili jako nejvhodnější řešení.

    Zatím mám takovou představu, že napíšu aplikaci v C++ která bude obsluhovat akcelerometr, tu spustím hned při bootování a já si z ní budu nějakým způsobem v mě klientské aplikaci (napadlo mě udělat to přes Socket) odebírat data.

    Ale nejvíc by se mi líbilo využít mechanismy Linuxu (které moc neznám) a napsat to jako modul (říkám to správně?).

    Děkuji za pomoc


    Řešení dotazu:


    Odpovědi

    stativ avatar 24.3.2014 17:29 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Proč prostě nepoužiješ JNI?
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    24.3.2014 18:04 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Díky, už se na to dívám :-)
    rADOn avatar 24.3.2014 18:40 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Jestli to nema moc komplikovany protokol tak muzes videt na i2c primo z userspace.
    Zatím mám takovou představu, že napíšu aplikaci v C++ která bude obsluhovat akcelerometr, tu spustím hned při bootování a já si z ní budu nějakým způsobem v mě klientské aplikaci (napadlo mě udělat to přes Socket) odebírat data.
    Cili spousta srani pro nic za nic. Pokud se to cely nema zasekavat na blokujicim cteni, budes muset napsat select/poll handler a postavit nad tim protokol na posilani zprav. To uz mas jednodussi psat si navzajem do sdileny pameti, tam se musis starat akorat o atomicitu. Ale jestli se opravdu chces s takovou silenosti matlat, tak existujou hotovy protokoly (dbus, corba, ice…)
    Ale nejvíc by se mi líbilo využít mechanismy Linuxu (které moc neznám) a napsat to jako modul (říkám to správně?).
    Jestli myslis modul do kernelu kterej by rozumel primo protokolu toho cipu, to by bylo nejlepsi. Ale jestli se musis na takovou vec ptat tak je to, bez urazky, zcela mimo tvoji ligu. Jinak je nejbeznejsi praxe ze co se nevejde do kernelu se zabali do pekny userspace knihovny s nejakym peknym API v C nebo prinejhorsim C++ a to pak jde nalinkovat vicemene z jakyhokoliv slusne vychovanyho jazyka. Coz je v jave to vyse zminene JNI.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    25.3.2014 00:45 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Děkuji, použiju JNI.

    Jen informativně, jak fungují vlastně ty soubory v /dev? Nešel by nějaký takový vytvořit a komunikovat přes něj s tím ovladačem MPU6050 napsaným v C/C++?
    rADOn avatar 27.3.2014 17:41 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Soubory v /dev spravuje a udrzuje primo jadro, to je "kralovstvi nebeske". Pokud bys chtel komunikovat pres soubor tak zalozis trubku pres mkfifo (1), do ni pak muze jeden proces psat a jinej cist a tim spolu kecat. Ale komunikace pres fifo ma takovou vlastnost ze kdyz neni co cist tak se cteci proces zablokuje. To je sice sikovny pacz tim pusti procesor delat neco uzitecnyho (treba zrovna ten zapisujici proces) ale pro rizeni letajicho hardwaru (a obecne rt ulohy) asi neni uplne dobry kdyz se ti proces na predem neznamou dobu zastavi. Proto se to pouziva spis pro zpracovani dat ve stylu fronty a ne na rizeni veci. (Neblokujici cteni pro jednoduchost vynechavam, to ma zase jiny problemy. Zvracenosti jako nechavat si posilat "vyprostovaci" signal casovace jsou svyho druhu reseni, ale je to takovej narovnavak-na-ohejbak.) Na komunikaci s hotovou knihovnou se hodi spis RPC a to se dela asynchrone pres socket jak jsem psal vyse.

    Vsechno tohle zahrnuje prinejmesim nejakou de/serializaci coz je podstatne komplikovanejsi (a ma z hlediska RT ulohy nezanedbatelny overhead) nez volat tu knihovnu primo. I kdyz to pozenes pres hotovy protokol (ted je zrovna v kurzu dbus) tak s tim bude dost prace navic. Jestli je nejaky problem napsat si wrapper (nemuzu posoudit, nikdy jsem JNI v ruce nemel) tak asi Java neni "slusne vychovany jazyk".
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    rADOn avatar 27.3.2014 17:51 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Podle toho co se pise tady neni cteni pres i2c zadnej problem, akorat clovek musi vedet spravny adresy a konstanty. Coz bude asi to co dela ta knihovna… Takze mozna nejjednodussi bude najit knihovnu na smbus a napsat si ten ovladac celej.

    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    27.3.2014 20:47 Sten
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Proč vynecháváte neblokující volání (resp. jaké problémy dle vás má)? Vždyť je přeci přesně to, co by RT úlohy měly používat. Pro časování se pak používá message loop postavená na select nebo epoll, což by ale RT úlohy měly používat tak jako tak.
    rADOn avatar 27.3.2014 23:18 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ja jsem nepsal ze rt ulohy nemaji pouzivat neblokujici cteni! Psal jsem ze to neni "reseni" blokovani roury, protoze pokud neco takovyho potrebuje tak to muze honit rovnou nad socketem. A select()/poll() jsem zminoval vyse. Rouru jsem zminil jen proto ze se tazatel ptal na komunikaci "pres soubor".

    Stejne je to jen akademicka debata, pacz na tazateluv problem je to prekomplikovany a nejspis ani nechape o cem je tady rec :-)
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    Josef Kufner avatar 27.3.2014 22:04 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    A nebylo by lepší tu javovou aplikaci přepsat do C++ a Qt? Odpadnou komplikace s knihovnou a budeš to mít rychlejší a míň nenažrané, což by se na Malině mohlo hodit. Qt má slušný event loop, integrovanou implementaci stavových automatů a dobrou dokumentaci.
    Hello world ! Segmentation fault (core dumped)
    rADOn avatar 27.3.2014 23:27 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    To by bylo urcite lepsi a jednodussi. A prave proto kdyz nekdo pri smyslech a dusevnim zdravi napise ze to pise v Jave, tak soudim ze o lepsi a jednodussi reseni nema zajem a nema cenu to ani zminovat :->
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    28.3.2014 01:30 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Jenomže ja v C++ pořádně neumím, to jednak (ale pořád bych byl ochoten se naučit) ale za druhé mám problém s kompilací - s Javou si klienta klidně napíšu ve svých Winech v NetBeans, tam si ho i zkompiluju, přetáhnu do RPi jar a rovnou to spustím (popřípadě můžu i debuggovat přímo z RPi v NetBeans). Ono jaksi kompilovat C++ nebo nedej bože to i psát rovnou na RPi to bych fakt nechtěl.

    A za třetí, odmítám si dělat servrovskou část v C++, Qt rozhodně používat nechci, jak na RPi (tam nepotřebuju GUI), tak u serverové aplikace - a to proto, že stejně nepodporuje tolik možností (např. různé eventy nad objekty gui, jako je odchyt souřadnic kurzoru apod.) jako Java nebo C# - je to pro moje budoucí povolání programátora ztráta investovat do takové věci čas, už jsem Qt zkoušel a odinstaloval to hned co jsem zjistil, že si tam některé věci budu muset komplet celé napsat, když jsem potřeboval udělat jeden projekt. Tak proč se to vůbec učit když to můžu dělat v Javě a mám spoustu času ušetřeno? Java je fajn a ve všech směrech mi vyhovuje.

    Jinak ano, uznávám, profík programátor v C++ je borec a špička, ale moje stanovisko je, že nechci trávit u PC zbytečně moc času. Já hodlám být ten střední proud :-)
    rADOn avatar 28.3.2014 10:33 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    No nerikal jsem to? Jsme jen banda idiotu, skutecny (budouci :-) ) programator se pozna podle toho co vsechno nechce a nepotrebuje znat.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    pavlix avatar 28.3.2014 11:15 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    28.3.2014 11:51 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    To jsem vůbec neřekl, snad můžu mít svůj názor

    Děkuju za vysvětlení.
    pavlix avatar 28.3.2014 11:59 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    rADOn je holt v tomhle ohledu trochu přísnější. Všichni víme, že Java je the cool enterprisy programming language. Python je příliš amatérský a C++ je příliš low level pro bežného aplikačního programátora.

    Nicméně, co jsem vůbec nepochopil je, co se tu vlastně řeší. V nadpisu je komunikace běžících aplikací, ale pak se řeší I2C a mezitím JNI. To je fakt děsivý mišmaš. Pokud člověk chce jen komunikaci mezi aplikacemi, tak prostředky systému jdou najít pod klíčovými slovy pipe a socket. High-level programovací jazyky a knihovny poskytují prostředky většinou na socketech postavené, tudíž jaksi není co řešit.
    stativ avatar 28.3.2014 15:19 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Nicméně, co jsem vůbec nepochopil je, co se tu vlastně řeší. V nadpisu je komunikace běžících aplikací, ale pak se řeší I2C a mezitím JNI. To je fakt děsivý mišmaš. Pokud člověk chce jen komunikaci mezi aplikacemi, tak prostředky systému jdou najít pod klíčovými slovy pipe a socket. High-level programovací jazyky a knihovny poskytují prostředky většinou na socketech postavené, tudíž jaksi není co řešit.
    Je to tu celé nějak zmatené. Ale vzhledem k tomu, že tazatel evidentně nemá moc chuť do C/C++, ale přitom má Céčkovou knihovnu, která umí všechno, co potřebuje, tak mi přijde jako nejschůdnější udělat okolo té knihovny malý wrapper pomocí JNI a pak už jen používat Javu.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    pavlix avatar 28.3.2014 22:38 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    rADOn avatar 28.3.2014 15:28 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    executive summary: Jde tady o to ze tazatel jako spravny javista zacatecnik vymejsli narovnavak na ohejbak. Ale protoze projevil vice invence nez bezni entrprajs frikulini tak jsem ho nechtel odbyt s "je to blbost, nedelej to" a snazil jsem se trochu osvetlit jak a na na co se v realu pouzivaji ta ruzna sprosta slova ktera se tu padla. Jak vidno, marna snaha, javisti jsou proste nepoucitelni :-)
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    pavlix avatar 28.3.2014 22:42 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Nebuď zlý. Náhodou se mi stalo, že pracuju ve firmě, kde je javistů jak nasráno a musím říct, že o nás linuxácích a našich způsobech nemají zrovna valné mínění. Tak proč je v tom ještě pomáhat. Stačí, že se musejí mordovat s tou Javou, která na první pohled působí hrozně uceleně a jednoduše a teprve potom se ukáže, co to všechno obnáší, aby to vůbec trochu jelo.
    rADOn avatar 29.3.2014 00:15 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Zlej? Kdybych chtel bejt zlej tak mu poradim uplne jiny veci :-)

    BTW v javovy firme jste taky delal, dokonce jsem tam tu javu psal... kde myslis ze se moje extremisticky nazory na javu vzaly? :-) No vlastne tam tak uplne ne. Extremisticky zacaly bejt az kdyz jsem v soucasnym jobu dostal pricuchnout k C++. S linuxackymi zpusoby nebyl problem, spis naopak. Kdyz jsem nekdy treti den zjistil ze se nestydi psat "programy" na preklapeni csvcek do sql insertu tak jsem nazhavil awk a razem byli linuxaci a jejich zpusoby oblibeny :-p
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    pavlix avatar 29.3.2014 09:48 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Tož u nás se Java tuším objevila nějakou velkou akvizicí, takže to je něco jako dvě firmy pod jednou střechou. Já jsem ani tak nemyslel způsoby práce jako způsoby chování, když se někdo zeptá na řešení v linuxáky neoblíbeném prostředí ;).
    28.3.2014 16:45 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Abych celý problém objasnil, ten modul, pro který mám ovladače v C++, je MPU6050 - gyro s akcelerometrem. Ano, komunikuje přes I2C, ano, dají se z něj normálně získávat raw údaje z gyra a akcelerometru, ale on si je umí i sám uvnitř zpracovat (dělá fůzi z gyra a akcelerometru což je nutné, jinak se to nedá praktikcy pořádně použít) a to obstarává právě ta knihovna, která je mimochodem pro tento modul jediná co existuje; takže ne, nejedná se jen o prostou komunikaci přes I2C, proto musím tu knihovnu použít :-)

    Zkoušel jsem JNI ale poněvač jsem nezjistil, jak uchovat proměnné, které se vyvořily při inicializaci modulu, tak jsem to předělal nakonec na Socket a funguje mi to, ačkoliv mám trochu obavy z narůstajícího zpoždění, už teď to není ideál.

    Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?
    stativ avatar 28.3.2014 17:22 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Zkoušel jsem JNI ale poněvač jsem nezjistil, jak uchovat proměnné, které se vyvořily při inicializaci modulu, tak jsem to předělal nakonec na Socket a funguje mi to, ačkoliv mám trochu obavy z narůstajícího zpoždění, už teď to není ideál.
    Pokud nejdou použít globální proměnné, tak bych se ještě podíval na použití NewGlobalRef pro vytvoření globální reference.
    Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?
    To ti nikdo přesně neřekne, muselo by se to vyzkoušet oboje a porovnat. Troufám si ale tvrdit, že to bude o hodně.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    rADOn avatar 28.3.2014 21:53 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Jesli můžu, využil bych příležitost a zeptal se, o kolik je pomalejší volání konzolového příkazu přes EXEC(String command) (utility ServoBlaster která nastaví DMP modul na RPi kvůli změně PWM signálu do regulátoru motorů) než-li zavolání přímo funkce této knihovny z mé aplikace?
    To ti nikdo přesně neřekne, muselo by se to vyzkoušet oboje a porovnat. Troufám si ale tvrdit, že to bude o hodně.
    Hodne hodne moc. Nekolik radu. Vystreleni novyho procesu znamena kontext switch a uz jen to je draha operace. Ne jenom ze musis nakopirovat kodovej segment, musi planovac udelat svoje kolecko a takovy ty kernelovy veci. Docela velkej zarez je ze se vicemene invalidujou zahraty cache linky, by woko bych si tipnul ze to bude asi nejvetsi brzda. Plus takovy ty detaily jako nakopirovani enviromentu, commandlajny a nejaka ta knihovni omacka.

    Zavolani funkce primo z nalinkovany knihovny je otazka lookupu v tabuli symbolu a dereference pointeru. Nula nula nic. Proto se taky knihovny pouzivaji. Ve tvem pripade tam bude jeste rezie JNI pacz musis preklopit javovsky datovy typy na ceckovy, coz bude drazsi nez to samotny volani :-) ale ve srovnani s saskarnou kolem execu je to porad zanedbatelny.

    BTW tohle je ale akademicka otazka - dokonce i na raspi nebude rozdil okem viditelny. Pokud je to RT uloha, tak to daleko spis zabije nedeterminimismus. Pri execu musi kernel nabrat nakou pamet pro proces a kernelovy pameti pro novej task, coz muze zabrat jakykoliv cas mezi nulou a nekonecnem. Nula je samozrejne "normalni" stav, ale kdyz je masina pod tlakem (napriklad proto ze nejaky proces vyzral veskerou volnou pamet :-) a kernel zacne hledat co kde muze vysypat do swapu tak si muzes pekne pockat.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    29.3.2014 02:35 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    No z praxe se zdá, že cela sekvence "Prijem zpravy ze serveru a nalezite zavolat 4x EXEC pro 4 motory" trvá tak 50-60ms (protože když dám co 50ms odesílání zprávy ze serveru, tak už se mi to celé zahltí a motory začnou reagovat se zpožděním) a já si myslím že za to může ten exec().

    Nicméně nakonec to dělám v C++ a není to náhodou tak špatné :-)
    rADOn avatar 29.3.2014 10:29 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ze by jsi nakonec nebyl uplne beznadejnej pripad? ;-) Ja ti povim jedno takovy stary moudro.

    Kdyz umis jenom Javu, tak jsi javista. Kdyz umis pascal, tak jsi pascalista. Kdyz umis C tak jsi ceckar... Az budes znat tak tri-ctyri jazyky, tak si muzes rikat programator.

    BTW zahlceni se ti muze stat bezne. i2c je podstatne pomalejsi nez kod na cpu, pokud s tim nepocitas neni problem dostat sezrat a zpracovat toho vic nez kolik se ti pak povede skutecne poslat na drat. Jestli s tim nepocita ta knihovna tak si to budes muset nejak zaridit.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    Petr Bravenec avatar 29.3.2014 10:40 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ten zápisek, kde vysvětlujete, proč Javu a proč ne Qt se mi líbí. "Dělám v Javě a basta" je lepší, než "když já nevím..."

    Ale jestli to nakonec budete dělat v C++, dejte Qt ještě šanci. Qt není jen GUI, je to i spousta dalších užitečných věcí. Na server to zrovna není, ale pořád to bude jednodušší, než obsluhovat sockety v C++ jinak.

    Pro podobné prostředí (BeagleBone) vyvíjím aplikaci pro sběr dat - má to vestavěný http server, databázi a moduly pro komunikaci po sériovém portu, velká část je postavená na už hotových knihovnách: http://www.hobrasoft.cz/cs/fotomon/fotobot
    Petr Bravenec - Hobrasoft s.r.o.
    pavlix avatar 29.3.2014 11:05 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ale jestli to nakonec budete dělat v C++, dejte Qt ještě šanci. Qt není jen GUI, je to i spousta dalších užitečných věcí. Na server to zrovna není, ale pořád to bude jednodušší, než obsluhovat sockety v C++ jinak.
    Je spousta knihoven s event loopem popřípadě zapojitelných do prakticky libovolného event loopu a čtení a zápis do socketu zvládnou všechny tak nějak podobně.
    29.3.2014 15:07 gld17 | skóre: 4 | blog: GLDiuv_blog
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Jo dělám to v Qt na RPi, trochu jsem si ho přetaktoval (na 950MHz) ať to jede rychleji, kompilace sice i tak trochu trvá ale dá se to zvládnout :-)

    Chápu to správně, že Qt má svoje knihovny, jako třeba sockety nebo thready (prootže Linux používá pthreads), takže pak můžu jeden projekt napsaný v Qt bez problému zkompilovat na Linux i na Win?
    Petr Bravenec avatar 29.3.2014 15:50 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ano. Běžně vyvíjím aplikace pro Windows tak, že vše dělám v Linuxu a když potřebuji balík pro Windows, pouze předhodím programu qmake jiný spec soubor a přeložím aplikaci pro windows, instalační balík vyrobím pomocí nsis. Podobně se dají dělat aplikace i pro Android, ale tam je rozdíl v prostředí trochu větší. Mezi Linuxem na ARM a na x86 nebude rozdíl prakticky žádný.
    Petr Bravenec - Hobrasoft s.r.o.
    Josef Kufner avatar 29.3.2014 16:07 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Můžeš to kompilovat i na výkoném stolním PC a pak nahrát na RPi – viz návod, ale asi to půjde i jednodušeji.

    Implementace socketů a vláken v Qt je jen tenký wrapper okolo nativních funkcí, takže program napsaný v Qt používá na Linuxu pthread a klasické BSD sockety, stejně jako ostatní programy. Počítej ale s tím, že každá platforma má své speciality a i když se Qt snaží poskytnout univerzální API, ne vždy zvládne podchytit všechny detaily.
    Hello world ! Segmentation fault (core dumped)
    Petr Bravenec avatar 29.3.2014 17:24 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ještě k tomu "wrapperu okolo socketů": Qt je událostní. Sockety typicky používám tak, že vytvořím třídu QSocket, propojím s okolím a nechám ji být. Program pak většinu času tráví kdesi ve smyčce zpráv a až v momentě, kdy má socket nějaká data, můj program se o tom dozví a můžu data v nějaké metodě zpracovat. Je to pohodlnější, než se trápit s blokujícími io operacemi (program pak nedělá nic jiného, než čeká na zprávu), nebo periodicky kontrolovat socket selectem.
    Petr Bravenec - Hobrasoft s.r.o.
    pavlix avatar 29.3.2014 21:24 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Především je program v době zablokování technicky vzato mrtvý, neschopný reagovat na jakékoliv jiné události než tu jednu konkrétní, na které je zablokovaný. To se hodí tak u jednoduchých skriptů nebo ekvivalentních binárek.
    Josef Kufner avatar 30.3.2014 13:49 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Main loop v Qt a i jiných framworcích není nic jiného než šikovně udělané čekání se select, poll, nebo nějakou modernější variantou téhož. Události jsou jen nepřímá volání metody podle výsledku toho selectu uvnitř.

    Za zmínku stojí, že jedním z těch filedescriptrů je typicky i spojení na X server, kudy přichází informace o akcích uživatele a odchází příkazy ke kreslení na obrazovku. Totéž platí pro stdio.

    Ten program je zablokovaný úplně stejně jako při prostém blokujícím čtení z jednoho filedescriptoru, jen to systémové volání čeká na více filedescriptorech najednou a pak řekne, který to byl.

    Select není nějaké periodické čekání. Je to zablokování s timeoutem, aby program mohl čas od času pohnout animací nebo něco zatahat za nohu. Periodické čekání by vypadalo tak, že by se ve smyčce kontrolovalo, zda přišla data a když ne, tak by se chvilku spalo. Select to dělá naopak, chvilku čeká a pak řekne, že nic nepřišlo, ale když něco přijde, program to ví okamžitě.
    Hello world ! Segmentation fault (core dumped)
    pavlix avatar 30.3.2014 17:34 pavlix | skóre: 53 | blog: pavlix
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ten program je zablokovaný úplně stejně jako při prostém blokujícím čtení z jednoho filedescriptoru, jen to systémové volání čeká na více filedescriptorech najednou a pak řekne, který to byl.
    Čekání na události z více zdrojů je hlavním smyslem event loopů postavených nad nějakým systémovým voláním, které toto umožňuje.
    Select není nějaké periodické čekání. Je to zablokování s timeoutem, aby program mohl čas od času pohnout animací nebo něco zatahat za nohu.
    A na linuxu je i ten timeout zbytečný, vzhledem k dostupnosti timerfd lze časovač jednoduše považovat za další zdroj událostí, a též ho tak technicky realizovat.

    Podle mě to Petr napsal správně.
    Petr Bravenec avatar 30.3.2014 21:00 Petr Bravenec | skóre: 43 | blog: Bravenec
    Rozbalit Rozbalit vše Re: Způsoby komunikace dvou běžících aplikací
    Ono je celkem fuk, jestli jsem to napsal správně - použít select se dá všelijak. Myslím, že Josef podle toho popisu funkce selectu v nakonec používá select úplně stejně, ve smyčce, periodicky.

    Podstatná je jiná věc: Qt či jiný framework dokáže programátora této činnosti ušetřit, nabízí mu hotové, odladěné řešení. Navíc Qt některé věci uklidí transparentně i do jiných vláken, kde už pak postup blokující / neblokující + select nehraje roli.

    Pracovat s Qt nemusí být vždy jednodušší, ale připadá mi to trochu bezpečnější, není tam tolik míst, kde se dá něco pokazit.
    Petr Bravenec - Hobrasoft s.r.o.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.