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 13:22 | Zajímavý článek

Na stránkách spolku OpenAlt vyšel Rozhovor s Jaroslavem Tulachem o GraalVM – o kompilátoru umožňujícím v jednom programu kombinovat různé jazyky (Java, JavaScript, Ruby, R, C, C++, Fortran, Rust aj.), překládat do nativních binárek nebo si snadno vytvořit vlastní jazyk a použít při tom stávající ekosystém (debugger, profiler, IDE atd.).

xkucf03 | Komentářů: 0
dnes 11:55 | Komunita

Bylo spuštěno předobjednávání linuxových chytrých telefonů PINEPHONE v limitované edici BraveHeart. Cena telefonu je 149 dolarů. Cena dopravy do Česka je 15 dolarů. Telefony by mely být odesílány na přelomu prosince a ledna.

Ladislav Hagara | Komentářů: 3
dnes 02:22 | Pozvánky

Fedora 31 Release Party, tj. oslava nedávného vydání Fedory 31, se uskuteční ve středu 20. listopadu v Brně. Program přednášek bude upřesněn.

Ladislav Hagara | Komentářů: 1
dnes 01:11 | Nová verze

Příspěvek na blogu webové aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) představuje novinky a ukazuje náhledy nové major verze 1.10.0 této v programovacím jazyce Go naprogramované aplikace. Nově jsou například vedle sebe zobrazovány původní a nové verze obrázků.

Ladislav Hagara | Komentářů: 0
včera 22:33 | IT novinky

Společnost Docker stojící za stejnojmennou kontejnerovou technologií čelila vážným finančním problémům. Stávající investoři do ní ale vložili dalších 35 milionů dolarů a společnost Mirantis odkoupila Docker Enterprise.

Ladislav Hagara | Komentářů: 0
včera 16:11 | IT novinky

Od 24. listopadu bude možné předobjednat přenosný počítač Pocket Popcorn Computer (Pocket P.C.) s 1.2 GHz Quad-Core ARM Cortex-A53 CPU, 2GB DDR3 RAM, 32GB eMMC Memory, 4.95" Full HD IPS LCD a 3200 mAh Removable Battery. Počítač by měl být odesílán v květnu 2020. Předinstalován by měl být Debian 10.

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

Canonical věnoval nadaci UBports další telefony a tablety pro podporu vývoje Ubuntu Touch, tj. Ubuntu pro telefony a tablety. Vybraní vývojáři Ubuntu Touch je mohou získat zdarma.

Ladislav Hagara | Komentářů: 11
včera 09:33 | Zajímavý projekt

Společnost GitHub v rámci svého GitHub Archive Programu vytvoří několik off-line záloh open source softwaru nacházejícího se na GitHubu pro budoucí generace. První taková záloha všech aktivních repozitářů proběhne 2. února 2020 ve spolupráci se společností Pigl na jejich piqlFilmy a uložena bude v Arktickém světovém archivu. Případné obnovení ze zálohy by mělo být možné i za 1 000 let.

Ladislav Hagara | Komentářů: 7
včera 05:55 | Nová verze

Dnes a zítra probíhá v Praze konference Internet a Technologie 19 pořádaná sdružením CZ.NIC. Sledovat ji lze online.

Ladislav Hagara | Komentářů: 1
13.11. 19:44 | Nová verze

Brendan Eich, mj. autor JavaScriptu a několikadenní CEO Mozilly, představil v lednu 2016 webový prohlížeč Brave (Wikipedie, GitHub). Dnes byla vydána verze 1.0 tohoto webového prohlížeče. K dispozici jsou také balíčky pro Linux.

Ladislav Hagara | Komentářů: 11
Jaké hodinky nosíte (nejčastěji)?
 (26%)
 (6%)
 (14%)
 (54%)
Celkem 158 hlasů
 Komentářů: 11, poslední dnes 11:52
Rozcestník

www.AutoDoc.Cz

A fork() in the road

Na konferenci HotOS XVII (17th Workshop on Hot Topics in Operating Systems) konanou 12. až 15. května v Itálii byl přijat také vědecký článek s názvem A fork() in the road. Jedním z autorů je Andrew Baumann z Microsoftu a Microsoft daný článek již zveřejnil na svých stránkách (pdf). Dle autorů článku systémové volání fork() do moderních operačních systémů již nepatří a na školách by se o něm mělo mluvit pouze jako o historickém artefaktu.

11.4. 00:11 | Ladislav Hagara | Zajímavý článek


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

Komentáře

Vložit další komentář

11.4. 00:30
Rozbalit Rozbalit vše Re: A fork() in the road
Thanks to the success of Unix, future systems will be stuck supporting fork for a long time; nevertheless,
an implementation hack of 50 years ago should not be permitted to dictate the design of future OSes.
Zajímavé, že tohle říká zrovna Microsoft.
11.4. 09:39 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: A fork() in the road

Z Microsoftu je jen jeden ze čtyř autorů článku, ale i tak (a s ohledem na publikování přes Microsoft) se automaticky nabízí interpretace "nedokázali jsme to pořádně implementovat, tak to musí být k ničemu".

Článek samotný má hlavu a patu a stojí za přečtení (čímž netvrdím, že se vším souhlasím). Výjimkou je právě ten nechutně bulvární úvod, který sice perfektně plní úlohu přilákat pozornost (i médií), ale autoři se pak nemohou divit, že málokdo bude brát zbytek vážně.

11.4. 01:37 SGOrava
Rozbalit Rozbalit vše Re: A fork() in the road
Čo si autory anti-fork článku predstavujú ako náhradu ?
Josef Kufner avatar 11.4. 01:53 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: A fork() in the road
posix_spawn()
Hello world ! Segmentation fault (core dumped)
11.4. 02:12 SGOrava
Rozbalit Rozbalit vše Re: A fork() in the road
Nakoniec som prebehol článok a tam niečo spomínajú.

S vedomím že je to od MS tomu ale veľmi neverím.
xkucf03 avatar 11.4. 09:34 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: A fork() in the road

Nemám na to úplně jasný názor, ale našel jsem tohle, což mi přijde celkem rozumné: posix_spawn is stupid as a system call

Exactly. The number of useful and important things you can, want, and need to do between a fork and an exec is far too great to make it one call, in all but the simplest cases. I had this exact argument with a Windows API proponent who felt that fork+exec was crazy (not related to OOM issues, just having more than one call). But the number of flags and arguments you'd need to replicate that behavior is insane and you'd STILL run into situations where you can't do what you want.

Fork+exec definitely has its downsides in some of the technical implementation requirements, but from a higher level language perspective it's brilliant.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Josef Kufner avatar 11.4. 11:52 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: A fork() in the road
Na jednu stranu to je omezení, na druhou stranu takové omezení může přinést mnohem efektivnější a jednoduší implementaci procesů. Otázkou je, zda ta omezení jsou v praxi na obtíž a zda nejdou nějak přijatelně obejít. Přecijen, fork+exec není vůbec jednoduché implementovat zcela správně a už jsem několikrát viděl, že nějaký program nevyčistil svoje prostředí a předal potomkům něco, co předat neměl (a pak zůstane otevřená zvukovka nebo nejde odpojit flashka).
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 11.4. 12:02 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: A fork() in the road

A nestačí mít nějaký rodičovský proces, který toho obsahuje minimum, má otevřené jen nezbytně nutné zdroje… a jen spouští podprocesy (které už s těmi různými zdroji pracují)? Ono asi dělat fork() „z prostředka“ běhu větší aplikace není úplně šťastný nápad (tam by asi zase bylo lepší použít vlákna).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Josef Kufner avatar 11.4. 12:08 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: A fork() in the road
Jeden takový případ je/bylo, když z Thunderbirdu či Firefoxu otevřeš přílohu mailu nebo stažený soubor. To jinak než „forkem z prostředka“ neuděláš. Možná by dávalo smysl to spouštět přes DBus, ale to je zas zbytečně komplikované.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 11.4. 12:21 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: A fork() in the road

Komplikované… zrovna v tomhle případě mi přijde lepší zavolat nějakou službu desktopového prostředí (třeba přes ten D-Bus). Pak to máš i jednotné a dokumenty se ti otvírají v aplikacích, které sis nastavil, ale ne že si to bude řešit každý po svém a jeden typ souboru se ti bude otvírat pokaždé v jiné aplikaci podle toho, jestli jsi na něj klikl ve Firefoxu, Dolphinu nebo Chromiu atd.

Případně by to šlo řešit tak, že by ta složitější aplikace měla jeden rodičovský proces a pak potomky, ve kterých by běželo GUI a všechno ostatní… a kdyby některý z těchto potomků chtěl spustit externí program, tak by o to požádal svůj rodičovský proces a nedělal by fork() sám.

Jinak nemám nic proti tomu, aby existovalo nějaké jednoduché standardní API pro spuštění nezávislého procesu. Ale nemyslím si, že by to měla být jediná cesta pro spouštění procesů.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
11.4. 13:05 tomo_tn
Rozbalit Rozbalit vše Re: A fork() in the road
Co je zle na volani "system("xpdf aaaBBBccc.pdf &");"?

Osobne moc neprogramujem ale ked som potreboval nieco z cecka spustit tak to vzdy fungovalo spravne o nejaky fork() som ani nezavadil. Fork mi prisiel ze je skor na multithreadove programovanie.
11.4. 15:28 hanzz
Rozbalit Rozbalit vše Re: A fork() in the road
The system() library function uses fork(2) to create a child process that executes the shell command specified in command using execl(3) as follows:

execl("/bin/sh", "sh", "-c", command, (char *) NULL);
11.4. 15:52 tomo_tn
Rozbalit Rozbalit vše Re: A fork() in the road
OK je jasne ze niekde "hore" je fork(). Popravde som ani netusil ze to ide aj inak. Ale pre naprogramoviane funkcie "otvor toto v programe XYZ" istotne nemusim zapolit z funkcoiu fork(). system() to pre mna zapuzdri do priamociaro pouzitelnej podoby.

O system lvl implementacii fork()-u som absolutne neni schopny polemizovat. Pokial viem tak kernel/ libc (doplnte si svoju implementaciu) sa snazia o maximalnu rychlost pri spustani novych vlakien/ uloh. To ze overhead pritom bude nenulovy nieje nutne polemizovat. Popravde ma moc nenapada uloha z realneho sveta kde fork() zaberie viac casu nez samotna uloha.

Vid stranka - polozka "Thread creation/joining" http://www.etalabs.net/compare_libcs.html
11.4. 16:17 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: A fork() in the road
Samozřejmě, že ve svých programech nemusíš zápolit s fork(), pokud ti stačí jeho obalení pomocí system().

Kvůli tomu taky ten microsofťák nebrečel. Brečel kvůli tomu, že ačkoli má na nějaké věci zjednodušení typu system(), tak se mu stejně nepodařilo udělat moderní operační systém tak, aby se bez toho fork() někde uvnitř obešel a že mu potom jeho moderní operační systém, psaný od začátku nakonec stejně připomíná unix, ačkoli se tomu chtěl za každou cenu vyhnout.

Stejně tak nemusíš zápolit se zásobníkem a registry, abys mohl psát (klidně i rekurzivní) funkce s lokálními proměnnými a provádět s nima výpočty. O to už se něco postará, ale nakonec tam někde dole budou ty registry a zásobník použité, i když ty s tím přímo do styku nemusíš přijít nikdy. Ale kdo bude psát nový OS a ošetřovat v něm přerušení a drivery pro nejrůznější zařízení, tak k tomu občas bude potřebovat přístup a brečet, že je to už 50 let starý koncept a že bys to chtěl bez něj, tak ať se o to ostatní postarají a nějak udělají, abys to nepotřeboval ani používat přímo, ani mít zabudované někde hluboko v systému - to ani mě ani tebe asi nenapadne. Ale kam se my dva hrabeme na inženýry z MicroSoftu, že ...
xkucf03 avatar 11.4. 15:44 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: A fork() in the road

Jak řešíš případy, kdy název souboru obsahuje mezery?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
11.4. 16:03 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: A fork() in the road
Pokud moc neprogramuješ a stačí ti volaní system(), tak na jeho použití není zlého nic. Jen jsou tu dva zádrhele: A) System() používá fork(), B) někteří programují víc a potřebují dělat i složitější věci, na které samotný system() nestačí a ti fork() potřebují.

Multithredové programování má spoustu velice užitečných použití, a to, že ty osobně jsi ho zatím třeba nepotřeboval na tom nic nemění.

Čili i kdybys nějak složitě naimplementoval system() tak, aby nepoužíval fork(), tak to stejně na potřebě fork() pro jiné účely nic nezmění. Samozřejmě pokud už máme fork(), tak se pomocí něj system() udělá jednoduše.
xkucf03 avatar 11.4. 16:42 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše volání system()
Pokud moc neprogramuješ a stačí ti volaní system(), tak na jeho použití není zlého nic. Jen jsou tu dva zádrhele: A) System() používá fork(), B) někteří programují víc a potřebují dělat i složitější věci, na které samotný system() nestačí a ti fork() potřebují.

Se system() bude problém i u celkem základních úloh. Příkaz se předává včetně svých parametrů jako jeden textový řetězec, takže se tam ztrácejí hranice mezi jednotlivými parametry – nemůžeš jen tak poslepovat řetězec ze vstupů, které si odněkud získal, protože v těch vstupech můžou být třeba mezery (např. v názvu souboru) a musíš to správně escapovat. Předávat si zde strukturovaná data ve formě textu je zlo – jednak je to nesmyslné, protože ty ten řetězec musíš poskládat a vzápětí ho Bash parsuje, a jednak je to náchylné k chybám (viz třeba nedávná chyba dirty sock ve snapd, kde si taky předávali strukturovaná data ve formě textu a samozřejmě se jim to rozsypalo – až tak moc, že z toho byla lokální eskalace práv…). O otravné práci navíc ani nemluvě.

Zajímavé by mi přišlo, mít nějakou možnost asynchronního spouštění procesů. Měl bys frontu (buď pro uživatele, relaci nebo aplikaci) a ta by měla nastavený nějaký maximální počet procesů. A do té fronty bys pak mohl sypat1 požadavky2 na spuštění procesu. Nějaký démon by tyhle procesy postupně spouštěl (pokud by pro ně byly volné procesy, jinak by čekaly ve frontě, než na ně přijde řada). Volitelně by ses mohl dotazovat na výsledek (stavový kód, dobu běhu atd.) nebo se přihlásit k asynchronnímu odběru událostí – dostal bys informaci, že proces skončil nebo že třeba něco vypsal na standardní výstup.

[1] ať už přes D-Bus nebo nějakou C funkci
[2] strukturovaně – tzn. ne jen jeden textový řetězec, ale hezky název programu, jednotlivé parametry, proměnné prostředí atd.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Heron avatar 11.4. 18:38 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: volání system()
Zajímavé by mi přišlo, mít nějakou možnost asynchronního spouštění procesů.
Něco takového jsem si před časem ubastlil. Potřeboval jsem spouštět úlohy (řádově desetisíce relativně malých úloh) na různých strojích na síti, vkládat (atomicky, asynchronně) úlohy do fronty, případně je mazat apod. Výsledek (stdout, stderr, exitcode) se uloží k hotové úloze (ne že bych to někdy skutečně použil, stačí, když to v pořádku doběhne). Na jednotlivých strojích si pustím tolik workerů, kolik chci (ručně, šla by udělat i systemd unita). Vím, že existuje hromada složitých programů pro clustery a pro gridy, ale já fakt hledal "něco jako" | parallel, ale s možností ty úlohy vkládat postupně a ze sítě. Využil jsem vlastnosti SKIP LOCKED v PG, čímž je fronta rovnou i atomická a současně je to síťové bez práce. V ideálním případě by to mohlo být i distrubuované, aby tam nebyla ta centrální db, ale to už by se zase blížilo těm hotovým grid bazmekům.
11.4. 21:26 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: volání system()
To mi je celkem jasné, ve sporu nejsme, ale pokud tomo_tn "moc neprogramuje", tak to beru, ze si sem-tam napise neco pro sebe, co by melo vetsinou fungovat aspon nejak a kdyz to obcas spadne, tak to spusti znovu, nebo upravi tak, aby mu to příště s těmito parametry nespadlo. A protože není blbý, tak ty parametry tomu většinou zadá "správně", což pro domácí použití stačí.

Kdyby psal hodně, nebo dělal nějaké široce sdílené věci, tak by dávno věděl víc a psal o tom jinak (můj pocit i na základě jeho příkladu a argumentace). A tam už by ty mezery a (jak zmíněno níže i útoky) řešit musel a asi taky řešil.

(Taky jsem si kdysi, asi tak koncem minulého milénia, napsal bandu bashových skriptů pro zálohování na CDčka (včetně indexování a kontrolních součtů a později i dalších parametrů souborů), které v prvních verzích neřešily ani mezery v názvech, později (když už jsem přejmenovával tak dvacátý soubor) je tedy začaly řešit a časem začaly zvládat i uvozovky, apostrofy a zpětné apostrofy a závorky kulaté, hranaté i složené. Používal jsem je řadu let a pro doma mi to stačilo. Ačkoli mi je lidi chválili, tak si je vzali tak asi dva až tři a moc je nepoužívali, na žádné chyby si nestěžovali. Kdyby se to rozšířilo trochu víc, tak už bych to přepsal do nějakého lepšího jazyka (C, Pascalu, ...) a řešil tam i "podivnosti", ale protože když to mělo problémy, tak to spadlo hned a napsalo s jakým souborem, tak pro doma jsem prostě soubor přejmenoval a jel dál. Svou úlohu to tehdy splnilo a víc jsem od toho nechtěl. Dnes už by mi přišlo jednodušší použít lepší jazyk rovnou a všechny tyto potenciální problémy pořešit.

Stejně tak můj první generátor statických webovek byl v M4 a používal make a léta mi sloužil i když vyžadoval, aby zdrojáky těch webovek byly dobře uzávorkované. Pak jsem používal nějaké jiné a dnes bych ho psal zcela jinak. Ale bylo to jen pro mě a já věděl, jak to pracuje a jaký vstup tomu musím připravit, tak to stačilo tak.)
11.4. 16:59 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: A fork() in the road
Multithredové programování má spoustu velice užitečných použití, a to, že ty osobně jsi ho zatím třeba nepotřeboval na tom nic nemění.
Ja se treba cim dal tim vic priklanim k myslence, ze vicevlaknovy beh aplikaci je pouze uspesny omyl, ktereho se budeme jeste dlouho zbavovat. Z meho pohledu je to velmi spatna abstrakce, ktera prinasi vic problemu nez resi.

Jsou lidi, kteri zastavaji nazor, ze vlakna v Unixech nemaji co delat (uz jenom kvuli problemum s fork()) a myslim, ze by se dalo bez vlaken velice pekne obejit, ... kdyby v Unixu bylo rozumne IPC.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 11.4. 17:25 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: A fork() in the road

Můžeš uvést nějaký příklad „rozumného“ IPC?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
11.4. 19:39 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: A fork() in the road
U me zatim vede ZMQ. A mit k tomu peknou podporu v prog. jazycich podobne jako ma Go pro kanaly, myslim, ze spouste programatoru by s takovou vlakna nechybela.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 11.4. 20:17 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše IPC

A musíš to mít nutně v UNIXu/POSIXu? Vždyť tohle se dá řešit právě těmi knihovnami a frameworky. OS je většinou o úroveň níž, řeší sdílenou paměť, procesy, MQ atd. – a nad tím už si postavíš API jaké potřebuješ. A co jsem četl, tak:

Goroutines are multiplexed onto multiple OS threads

tzn. je to akorát abstrakce nad vlákny a takové knihovny existují ve všech možných jazycích.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
11.4. 22:39 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: IPC
A musíš to mít nutně v UNIXu/POSIXu?
Nemusim. Podstata meho sdeleni byla v tom, ze kdyby to tam bylo, rada veci by se dala delat jinak a lip.
Goroutines are multiplexed onto multiple OS threads
tzn. je to akorát abstrakce nad vlákny a takové knihovny existují ve všech možných jazycích.
Ale to reagujes uplne na neco, o cem nemluvim a co ani neni dulezite. Ja se tu bavim o podpore IPC na strane jazyka.

Pokusim se to rozebrat trosku obsirneji. Vlakna jsou prilis lakavy koncept na to, nezaclenit ho do OS. Na urovni jadra jejich podpora neni slozita, podpurneho kodu v uzivatelskem prostoru taky neni moc potreba. Pridani vlaken do vyssich programovacich jazyku je trivialni. Neni potreba nijak upravovat jazyk. Programator muze sdilet data mezi vlakny, nemusi nic resit. Muze programovat tak, jak programoval vzdy, jen se tu a tam prida nejaky ten zamek nebo semafor.

IMHO toto zdanlive pohodli stoji za uspechem a celkovou mizerii prace s vlakny. Pokud mas jednovlaknovy program, da se nad kodem rozumne uvazovat stylem if-neco-tak-neco. V pripade vicevlaknovych aplikaci toto absolutne pada, ztracis garance temer vseho. Sdilena data v rezimu pro zapis jsou na uchopeni jeste horsi nez pouzivani globalnich promennych a goto dohromady. Pristup k datum muzes zamykat, ale kolik lidi dokaze napsat kod, ktery nebude obsahovat nejaky skryty race-condition nebo deadlock?

A kdyz jsem tak chytrej, co ma byt teda alternativou? Jako mnohem cistejsi mi prijde vytvorit samostatne (oddelene) procesy, ktere mezi sebou komunikuji zasilanim zprav. Takto nejenom, ze neztratis ruzne garance jako v pripade vicevlaknovych aplikaci, ale stale muzes nad kodem uvazovat stylem if-neco-tak-neco. Odpadne ti velke mnozstvi starosti, ktere plynou z toho, ze jedno vlakno muze zapsat/cist cokoliv, co patri tomu druhemu.

Dalsi bonus, ktery tim ziskas, je modularita. Tim, ze jednotlive procesy mezi sebou komunikuji zasilanim zprav, ziskas jednoznacne definovane a testovatelne rozhrani mezi jednotlivymi castmi kodu! (cf. chuchvalec vlaken sdilejici, co zrovna potrebuji). Ze to jde a dava smysl, ukazuje treba architektura Chromu.

Proc se tento pristup nepouziva vic, je podle me tim, ze celkove aparat, ktery poskytuji soucasne IPC+programovaci jazyky neni, pro programatora tak komfortni jako vlakna. Kdyby se to zjednodusilo na uroven treba Erlangu nebo kanalu v Go, asi by potom sahlo vic programatoru. A kdyz se to zjednodusi jeste vic, tak to budou lidi pouzivat aniz by tusili, ze vlastne nejake IPC pouzivaji, viz roury mezi programy. A tim se dostavam zpatky k uzitecnosti fork().
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
11.4. 23:17 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: IPC
Proc se tento pristup nepouziva vic, je podle me tim, ze celkove aparat, ktery poskytuji soucasne IPC+programovaci jazyky neni, pro programatora tak komfortni jako vlakna.

Spíš výkon a paměťová náročnost. Jak jste správně podotkl, napsat pořádně složitější multithreadovou aplikaci je těžké. Kdyby to nemělo své výhody, proč by si s tím vývojáři dávali tu práci?

11.4. 23:51 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: IPC
Spíš výkon a paměťová náročnost.
Nejsem si jisty, do jake miry je toto jeste skutecny problem. Obzvlast ve svete, kde rada vyvojaru si mysli, ze vzit vykreslovaci jadro z prohlizece se vsim vsudy k tomu dva runtimy pro javascript, ktere si mezi sebou vykladaji pomoci HTTP a udelat z toho desktopovou aplikaci, je dobry napad.

Ale dost sarkasmu. Rezie, kterou zasilani zprav, muze byt v nekterych situacich problem. I kdyz si myslim, ze toto je misto, kde bychom si dnes snad mohli dovolit polozit trochu vykonu na oltar bezpecneho programovani.
Jak jste správně podotkl, napsat pořádně složitější multithreadovou aplikaci je těžké.
Je to tezke, ale kdyz to clovek udela blbe, neni tam zadna prekazka nebo indikace, ktera by ho upozornila, ze to udelal blbe. Takze clovek snadno nebude dojmu, ze to zase tak tezke nebylo, i kdyz tam nechal treba potencialni problem.

Na druhou stranu, pokud mas izolovane moduly, u kterych musis navrhnout dobre rozhrani pro vymenu dat, uz to boli (dobry navrh rozhrani vzdy boli) a prostredky, ktere prog. jazyky nabizi, to nedelaji vubec jednodussi.
Kdyby to nemělo své výhody, proč by si s tím vývojáři dávali tu práci?
Ze setrvacnosti? Z falesneho pocitu, ze to prece neni tak slozite a ze to zvladnou?

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 11.4. 23:42 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: IPC

Souhlasím, že pracovat s vlákny, řešit zámky a souběh je dost ošemetné a spousta programů tím trpí, je to častý zdroj chyb… Nicméně tohle srovnání mi nepřijde úplně fér:

Jako mnohem cistejsi mi prijde vytvorit samostatne (oddelene) procesy, ktere mezi sebou komunikuji zasilanim zprav. Takto nejenom, ze neztratis ruzne garance jako v pripade vicevlaknovych aplikaci, ale stale muzes nad kodem uvazovat stylem if-neco-tak-neco. Odpadne ti velke mnozstvi starosti, ktere plynou z toho, ze jedno vlakno muze zapsat/cist cokoliv, co patri tomu druhemu.

Protože sis to zjednodušil tím, že jsi úplně škrtl přístup ke společným datům a nahradil ho posíláním zpráv. Ovšem jak se to liší od vícevláknového programu, kde se akorát zdržíš sahání na jedna data z více vláken a místo toho si budeš posílat zprávy přes nějakou frontu?

Ono na úskalí vláken upozorňují i mnoho let staré knihy… a programátoři snad ve všech jazycích na tyhle problémy nějak reagují a vytvářejí různé knihovny a abstrakce, které tu paralelizaci řeší. Takže já se na to dívám spíš tak, že vlákna nejsou nějaké bytostné zlo, ale jen nízkoúrovňový koncept, se kterým běžný aplikační programátor normálně nepřijde přímo do styku. Existují různá pohodlnější a bezpečnější řešení pro Javu, C++ a další jazyky. Dokonce jsem nedávno koukal, že programátor ZeroMQ napsal obdobu gorutin/kanálů v céčku: libmill.

Je otázka, jestli je pro tohle nutné mít podporu přímo v syntaxi jazyka – mít k tomu ten syntaktický cukr. Možná naopak kvalitu a pružnost jazyka dokazuje lépe to, že tam takovou věc šlo dopsat jako knihovnu a postavit to nad stávající univerzální syntaxí (ať už to jsou funkce, šablony nebo třeba anotace). V té pružnosti budou možná nejdál jazyky jako Lisp nebo Haskell (tipuji, nemám s nimi moc zkušenost), ale jak je vidět, realizovat to jde i v celkem běžných jazycích jako je C++ nebo Java.

Nemusim. Podstata meho sdeleni byla v tom, ze kdyby to tam bylo, rada veci by se dala delat jinak a lip.

Asi by to posloužilo jako jednotný návrhový vzor, ze kterého by implementace v jednotlivých jazycích vyšly. Souhlasím, že nějaká standardizace resp. jednotný vzor by nebyly od věci. Přesto by ale asi možnost ručně pracovat s vlákny nezmizela – stejně jako asi nezmizí možnost ručně spravovat paměť.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
12.4. 00:15 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: IPC
Jen tak na okraj ty vlákna jde používat i Pythonu a dalších podobných. A když se to udělá dobře a člověk s tím nedělá žádné velké vylomeniny, tak to tam jde i velmi jednoduše a zároveň to odvede spoustu dobré práce.
12.4. 00:16 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: IPC
Protože sis to zjednodušil tím, že jsi úplně škrtl přístup ke společným datům a nahradil ho posíláním zpráv
A to jde, zjednodusit si veci tak, aby se v tom clovek vyznal. Jinak data neni problem sdilet, pokud jsou nemenna nebo v rezimu CoW. Pokud potrebujes mit nejaky sdileny prostredek, da se odpovednost za nej jednomu procesu a ostatni to s nim vykomunikuji. Viz Rust.
Ovšem jak se to liší od vícevláknového programu, kde se akorát zdržíš sahání na jedna data z více vláken a místo toho si budeš posílat zprávy přes nějakou frontu?
Mas tam ty garance, ze ti zadne vlakno OPRAVDU nehrabe, kam nema. Zmizne ti, cela kategorie problemu, kterymi by ses musel zabyvat.
Ono na úskalí vláken upozorňují i mnoho let staré knihy… a programátoři snad ve všech jazycích na tyhle problémy nějak reagují a vytvářejí různé knihovny a abstrakce, které tu paralelizaci řeší.
A stale nic, co by slo rozumne pouzit. Treba v Jave jsou monitory, ale chybu udelas ani nemrknes, muj oblibeny vzor (i kdyz ve skutecnem kodu to byva jeste zasmodrchanejsi).
public class SharedData {
  private List<Object> data = new ArrayList<>();
  
  public synchronized void add(Object o) {
     data.add(o);
  }

  public synchronized List<Object> getData() {
     return data;
  }
}
Vsimni si, ze jsem udelal obe metody synchronized, tak to musi byt v poradku!
Takže já se na to dívám spíš tak, že vlákna nejsou nějaké bytostné zlo, ale jen nízkoúrovňový koncept, se kterým běžný aplikační programátor normálně nepřijde přímo do styku
Ja to vnimam spis jako spatne navrzeny (nedomysleny) koncept.
Existují různá pohodlnější a bezpečnější řešení pro Javu, C++ a další jazyky. Dokonce jsem nedávno koukal, že programátor ZeroMQ napsal obdobu gorutin/kanálů v céčku: libmill.
Neznal, jsem diky za info.

Je otázka, jestli je pro tohle nutné mít podporu přímo v syntaxi jazyka – mít k tomu ten syntaktický cukr. Možná naopak kvalitu a pružnost jazyka dokazuje lépe to, že tam takovou věc šlo dopsat jako knihovnu a postavit to nad stávající univerzální syntaxí (ať už to jsou funkce, šablony nebo třeba anotace).

Je opet spise podruzne, jestli to bude knihovna nebo soucast jazyka. Dulezite je, aby to bylo snadno pouzitelne s minimalnim usilim (viz erlang, go nebo roury). To je jeden z problemu, proc lidi dnes radeji sahnout po vlaknech a sdileni vseho, protoze je to pro ne pohodlnejsi.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 12.4. 11:51 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: IPC
Mas tam ty garance, ze ti zadne vlakno OPRAVDU nehrabe, kam nema. Zmizne ti, cela kategorie problemu, kterymi by ses musel zabyvat.

S tímhle se dá souhlasit, nicméně je to otázka přístupu – jestli nabídnout programátorovi jen omezené možnosti a nedovolit mu udělat chybu, nebo mu dát k dispozici víceméně všechno a jen ho varovat, že některé věci můžou být nebezpečné. Ono záleží dost na aplikaci/projektu – někde se hodí to omezené prostředí a někde naopak potřebuješ mít občas možnost dělat ty nízkoúrovňové a nebezpečné věci.

Vsimni si, ze jsem udelal obe metody synchronized, tak to musi byt v poradku!

Tohle je opravdu hodně učebnicový příklad chyby – v praxi to bývá pestřejší. Nicméně synchronized v Javě je hodně nízkoúrovňová věc, kterou využije spíš autor nějaké knihovny nebo frameworku než aplikační programátor, který se má soustředit na byznys logiku. Ten by měl používat nějaké vhodné knihovny a abstrakce, nějaké vyšší API a ne muset řešit tu synchronizaci takhle ručně.

Ja to vnimam spis jako spatne navrzeny (nedomysleny) koncept.

Což o to, operační systém by šel postavit i bez toho a mít jen oddělené procesy, které si mezi sebou posílají zprávy. Ale mělo by to asi dost negativní dopady na výkon. Ono i když nepoužíváš vlákna a máš jen procesy, tak si stejně mezi nimi někdy předáváš data pomocí sdílené paměti, protože prostě nechceš kopírovat velké bloky dat skrze nějakou rouru nebo zprávy. Tou zprávou si třeba jen předáš informaci, že ve sdílené paměti čekají nějaká data na zpracování. Takže vláken ses sice zbavil, ale ten obtížný úkol (přistupovat k jedněm datům z více procesů) tam máš stále.

A ty vyšší abstrakce bývají stejně postavené na nějakých zámcích, sdílené paměti, monitorech, vláknech… akorát od nich programátora odstíní, aby tyhle nízkoúrovňové mechanismy neviděl a nemohl v nich udělat chybu. Klidně můžeš mít API, které z pohledu programátora vypadá, že posílá zprávy, ale vnitřně bude ta data předávat přes sdílenou paměť, nebo můžeš mít jednoduché a bezpečné API pro paralelní zpracování, které ale uvnitř bude používat vlákna, akorát o tom programátor ani nebude vědět a nebude s těmi vlákny přímo pracovat – jen někam nasype úlohy a pak si jinde vyzvedne výsledky. A na tohle už existuje plno knihoven snad ve všech jazycích. Jak jsem psal – o úskalích vícevláknového přístupu se ví už dlouhé roky a řešení jsou.

To je jeden z problemu, proc lidi dnes radeji sahnout po vlaknech a sdileni vseho, protoze je to pro ne pohodlnejsi.

Nevím, nemám k tomu statistiku, nedokážu posoudit, kolik lidí to dělá. Na základě pozorování mi spíš přijde, že se dneska hodně lidí upíná k nějakým technologiím, o kterých si myslí, že je to stříbrná kulka, která za ně vyřeší všechny složité problémy a oni jsou v bezpečí… jenže ztrácí respekt a soudnost. Pak z toho vznikají takové chyby, jako že někdo sice používá Golang (to by přece mělo být bezpečné!), jenže v něm poslepuje textový řetězec z neošetřených vstupů a způsobí vážnou bezpečnostní chybu. Přitom byla patrně vadná už ta myšlenka předávat si strukturovaná data ve formě textového řetězce. Jenže když někomu nedocházejí takovéto základní věci, tak ho nezachrání ani „bezpečný“ jazyk.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
13.4. 14:21 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: IPC
S tímhle se dá souhlasit, nicméně je to otázka přístupu – jestli nabídnout programátorovi jen omezené možnosti a nedovolit mu udělat chybu, nebo mu dát k dispozici víceméně všechno a jen ho varovat, že některé věci můžou být nebezpečné. Ono záleží dost na aplikaci/projektu – někde se hodí to omezené prostředí a někde naopak potřebuješ mít občas možnost dělat ty nízkoúrovňové a nebezpečné věci.
Tato argumentace me nechava ledove klidnym. Uz jsem ji zazil pred cca 20 lety, kdy se vedly vasnive diskuze, ze garbage collectory jsou spatne, protoze maji rezii a ze programator potrebuje mit moznost "prasit" s pameti, aby dosahl nejlepsiho mozneho vykonu. Spravny programator(tm) chyby nedela, protoze vzdy uvolni pamet, atd. atd.,
Což o to, operační systém by šel postavit i bez toho a mít jen oddělené procesy, které si mezi sebou posílají zprávy. Ale mělo by to asi dost negativní dopady na výkon.

Docela oblibeny byl i argument, ze Java je zbytecne pomala, protoze pri kazdem pristoupu do pole testuje, jestli nahodou neprekrocils jeho mez, a ze spravny programator potrebuje pointerovou aritmetiku (a spravny programator(tm) si dokaze pristup za meze pole pohlidat sam).
Takže vláken ses sice zbavil
Minimalne jeden obri problem odstranen.
Ono i když nepoužíváš vlákna a máš jen procesy, tak si stejně mezi nimi někdy předáváš data pomocí sdílené paměti, protože prostě nechceš kopírovat velké bloky dat skrze nějakou rouru nebo zprávy. Tou zprávou si třeba jen předáš informaci, že ve sdílené paměti čekají nějaká data na zpracování.
Jednak tech mist, kde toto je realny problem bude IMHO docela malo. Intuitivne bych treba rekl, ze to bude i pripad renderovaci jadra prohlizece, ale prekvapive to zase takovy proble neni. Pokud potrebujes sdilet data jde to v rezimu pouze pro cteni (aniz by to delalo jakykoliv problem, na coz se vyborne hodi fork()) nebo je fajn, kdyz OS pro tyto veci nabizi zero-copy nastroje. (Tam trosku smerovala i ta poznamka o rozumnem IPC). A jeste jedna vec, sdilena pamet, do ktere muze zapisovat vice ruznych procesu/vlaken, neni dobry napad i ze softwarove inzenyrskeho hlediska. Za sdilene prostredky by mela byt zodpovednost vzdy na jednom miste...
A ty vyšší abstrakce bývají stejně postavené na nějakých zámcích, sdílené paměti, monitorech, vláknech… akorát od nich programátora odstíní, aby tyhle nízkoúrovňové mechanismy neviděl a nemohl v nich udělat chybu.
Aneb zameteme problem pod koberec, podobne jako kdyz stavis dum na pisku (muze to fungovat hezky, ale pak te to dozene).

Tyto abstrakce, protoze jsou postaveny na vlaknech, problem neresi jen skryvaji. Problem je, ze implicitne je povoleny jakykoliv pristup do pameti jakemukoliv vlaknu.

Predstav si, ze mas souborovy system, kde vsechny soubory maji povolene cteni i zapis (protoze kontrola opravneni ma prece dopad na vykon). Kontrolu budes delat jen tam, kde hrozi nejaky problem a nastavis si prava pro pristup (pouzijes zamek), s tim, ze kazdy program ma pravo ten zamek ignorovat (vykaslat se na kontrolu zamku). Prijde ti to jako dobre navrzeny souborovy system? A v pripade vlaken to povazujeme za normalni vychozi stav....
o úskalích vícevláknového přístupu se ví už dlouhé roky a řešení jsou.
To je hodne optimisticky nazor.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xkucf03 avatar 13.4. 15:18 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: IPC
Tato argumentace me nechava ledove klidnym. Uz jsem ji zazil pred cca 20 lety, kdy se vedly vasnive diskuze, ze garbage collectory jsou spatne, protoze maji rezii a ze programator potrebuje mit moznost "prasit" s pameti, aby dosahl nejlepsiho mozneho vykonu. Spravny programator(tm) chyby nedela, protoze vzdy uvolni pamet, atd. atd.,

Zřejmě jsi přehlédl tu část: „Ono záleží dost na aplikaci/projektu“. A před těmi dvaceti lety: dost možná to bylo taky nedorozumění vycházející z toho, že není nějaké jedno programování, ale že jsou různé úlohy/projekty vyžadující různé postupy. Asi jsi byl v roli aplikačního programátora a bavil ses s někým, kdo to nechápal a snažil se ti nacpat svoje nízkoúrovňové postupy, na které byl zvyklý a které pro svoji práci možná opravdu potřeboval, ale nechápal, že pro tvoji práci jsou nevhodné. Taky jsem to zažil.

Mě např. udivuje, kolik věcí se dodnes píše v tzv. čistém céčku, i když je to pro dané úlohy naprosto nevhodně nízkoúrovňový jazyk a bylo by lepší použít nějaký vyšší → méně kódu, méně chyb, zanedbatelný negativní dopad na výkon (nebo dokonce jeho zlepšení). Když už, tak mi tedy dává smysl apelovat na to, aby lidé psali ve vyšších jazycích a používali nějaké dobré knihovny, frameworky a návrhové vzory. A ne apelovat na to, aby se z těch nízkoúrovňových jazyků nebo systémů odstranily nějaké „nebezpečné“ funkce.

Docela oblibeny byl i argument, ze Java je zbytecne pomala, protoze pri kazdem pristoupu do pole testuje, jestli nahodou neprekrocils jeho mez, a ze spravny programator potrebuje pointerovou aritmetiku (a spravny programator(tm) si dokaze pristup za meze pole pohlidat sam).

Ale málokdo píše v Javě operační systém.

Aneb zameteme problem pod koberec, podobne jako kdyz stavis dum na pisku (muze to fungovat hezky, ale pak te to dozene). Tyto abstrakce, protoze jsou postaveny na vlaknech, problem neresi jen skryvaji.

Tak by to bylo, kdyby použití vláken (nebo třeba té sdílené paměti) vedlo vždy k chybě. Ale tak to není. Použití těchto věcí pouze zvyšuje pravděpodobnost, že programátor udělá chybu. A tu knihovnu, framework nebo operační systém by měl psát někdo dostatečně zkušený a pečlivý, aby tu chybu neudělal a měly by tam být i dostatečné QA procesy, které ty chyby eliminují. Pak to není dům na písku nebo střepy pod kobercem, ale spíš zbraň zamčená v trezoru, od které má klíče jen někdo zodpovědný a použije ji, až k tomu bude legitimní důvod.

Predstav si, ze mas souborovy system, kde vsechny soubory maji povolene cteni i zapis

To je jiný případ, protože souborová oprávnění chrání jednoho uživatele před jiným, který by mohl mít špatné úmysly – proto to nemůže být na dobrovolné bázi. Ovšem ty abstrakce chrání programátora, aby neublížil sám sobě resp. svému programu – proto na dobrovolné bázi být můžou. Pokud vytvoříš abstrakci takovou, že lidi stejně radši budou používat ty nízkoúrovňové nebezpečné postupy, tak ta abstrakce asi není dost dobrá a nemá kvality, které od ní její uživatelé vyžadují.

Ano, něco může být dané setrvačností – např. když se něco učí na školách nebo když je někdo zvyklý celý život sdílenou paměť a nechce se mu se učit nějaké nové knihovny. Ale tohle jednak nemůže trvat věčně (pokud jsou abstrakce užitečné, tak si k nim lidé cestu najdou) a jednak je to spíš chyba těch škol než toho, že existují nějaké nízkoúrovňové nebezpečné techniky.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
13.4. 16:53 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: IPC
Asi jsi byl v roli aplikačního programátora a bavil ses s někým, kdo to nechápal a snažil se ti nacpat svoje nízkoúrovňové postupy, na které byl zvyklý a které pro svoji práci možná opravdu potřeboval, ale nechápal, že pro tvoji práci jsou nevhodné. Taky jsem to zažil.
Ty diskuze byly napric softwarovou komunitou a tyto argumenty pouzivali bezne i lidi, co nedealali nic jineho nez mastili desktopove aplikace nad WinAPI.
Když už, tak mi tedy dává smysl apelovat na to, aby lidé psali ve vyšších jazycích a používali nějaké dobré knihovny, frameworky a návrhové vzory.
A v tech vyssich jazycich potkaji vlakna, ktera umoznuji pristupovat kdykoliv a k cemukoliv.
A ne apelovat na to, aby se z těch nízkoúrovňových jazyků nebo systémů odstranily nějaké „nebezpečné“ funkce.
Klidne at v tech nizkourovnivych vecech zustanou, ... ale jenom tam, ve vyssich programovacich jazycich je to pruser. Obzvlast, kdyz k tomu neni od OS rozumnejsi alternativa.
Ale málokdo píše v Javě operační systém.
Takze pro vyssi prog. jazyky dava smysl zavrhnout nizkourovnove koncepty na ukor toho, ze programy budou bezpecnejsi i kdyz mirne pomalejsi?

Tak by to bylo, kdyby použití vláken (nebo třeba té sdílené paměti) vedlo vždy k chybě. Ale tak to není. Použití těchto věcí pouze zvyšuje pravděpodobnost, že programátor udělá chybu.
Explicitni alokace/uvolneni/pristup k pameti taky nevede vzdy k chybe, ale je to nesporny zdroj problemu, a presto nikomu dnes neprijde divne, ze programovaci jazyky a jejich prostredi explicitne omezuji pristup k pameti, aby se temto problemum predeslo a programator nemohl udelat celou skalu chyb.
A tu knihovnu, framework nebo operační systém by měl psát někdo dostatečně zkušený a pečlivý, aby tu chybu neudělal a měly by tam být i dostatečné QA procesy, které ty chyby eliminují.
Takze misto toho, abychom se spolehli na to, ze urcite typy chyb vubec nenastanou, tak se budeme tiset spolehat na to, ze kazdy vi, co ma delat a kdyz nekdo chybu udela, tak ji nekdo vcas vsimne.
spíš zbraň zamčená v trezoru, od které má klíče jen někdo zodpovědný a použije ji, až k tomu bude legitimní důvod.
Pokud pristoupim na tve prirovnani, tak v takovem pripade, je to sice trezor, ale kteremu chybi zadni stena a kdokoliv si muze tu zbran vyzvednout, protoze neni zadny prostredek, ktery by mu v tom branil.
Ovšem ty abstrakce chrání programátora, aby neublížil sám sobě resp. svému programu – proto na dobrovolné bázi být můžou.
Podobne jako dynamicke a staticke typy. Jenomze s vlakny si muzes vybrat jen tu dynamickou variantu.
Ovšem ty abstrakce chrání programátora, aby neublížil sám sobě resp. svému programu – proto na dobrovolné bázi být můžou.
A chrani i tym programatoru pracujicich na jednom programu?
Pokud vytvoříš abstrakci takovou, že lidi stejně radši budou používat ty nízkoúrovňové nebezpečné postupy, tak ta abstrakce asi není dost dobrá a nemá kvality, které od ní její uživatelé vyžadují.
S tim se da souhlasit, viz moje prodchozi komentare, ze kdyby existovala v mainstreamovych jazycich a OS rozumna podpora IPC a procesu, bez vlaken bysme se obesli a meli bychom o radu problemu min.
Ano, něco může být dané setrvačností – např. když se něco učí na školách nebo když je někdo zvyklý celý život sdílenou paměť a nechce se mu se učit nějaké nové knihovny.
Byly doby, kdy globalni promenne byly standardem a jejich vymyceni dlouhy proces, ktery se dodnes nepodarilo dokoncit.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
xxx avatar 13.4. 21:19 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: IPC
Rika, se ze Internet nedela lidi blbjejsi, ale jen dela jejich blbost vice viditelnou. Stejny je to s parallelismem. Na te tride je to hezky videt. Je spatne, ale pokud by nedoslo na vlakna, tak by chyba uderila nejspis az nekdy pozdeji (nebo treba nikdy).

Paralelismus ma proste svoje uskali, ale myslim si, ze je celkem jedno jestli si clovek nabije nos na SIGSEGV nebo kdyz mu bude program (zcela korektne) cekat na zpravu co neprichazi. :-) Ani v jednom pripade si nemohu dovolit, psat stylem "sem pridam jeste mutex, treba to zacne fungovat", nebo ekvivaletne "sem pridam timeout kdyz neprijde zprava".

Podobny problem je to v C. Clovek nemuze mit pusteny Valgrind a pridavat free(), tak jak mu to "poradi", ale musi mit nejaky (myslenkovy) framework, jak pracuje s pameti. Ja proti GC nic nemam, stejne tak bych ocenil i to lepsi IPC, ale vidim zde spis prinos v tom, ze to odstrani trivialni chyby, nez ze by to byla spasa, a vlakna se dala pouzivat i po deseti pivech.
Please rise for the Futurama theme song.
Jendа avatar 11.4. 17:26 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: A fork() in the road
Pro začátek otevření souboru aaaBBB`rm -rf ~`ccc.pdf.
Bojíte se 5G sítí? Pořiďte si domů radar, který veškeré 5G sítě spolehlivě zaruší!
11.4. 13:02 Boban
Rozbalit Rozbalit vše Re: A fork() in the road
Zrovna ten Thunderbird tohle přes DBus na Fedoře dělá:
Apr 11 12:57:57 st dbus-daemon[3431]: [session uid=1002 pid=3431] Activating via systemd: service name='org.gnome.evince.Daemon' unit='org.gnome.Evince.service' requested by ':1.534' (uid=1002 pid=4432 comm="evince /home/mono/mono.pdf")
Apr 11 12:57:57 st systemd[2212]: Starting Evince document viewer...
Apr 11 12:57:57 st dbus-daemon[3431]: [session uid=1002 pid=3431] Successfully activated service 'org.gnome.evince.Daemon'
Apr 11 12:57:57 st systemd[2212]: Started Evince document viewer.
11.4. 13:06 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: A fork() in the road
no ten clanek od microsoftu pise, ze to zkouseli udelat jinak a obejit ten fork (a v jednoduchych pripadech jim to fungovalo, ale zjistili, ze zivot zase neni jen tak jednoduchy), ale ze to nedokazali a nakonec ho teda implementovali zas. Takze snaha byla, ale zjevne problemy se jim hromadily tak, ze to nakonec vzdali, i kdyz cilem bylo se toho forku zbavit zcela.
Conscript89 avatar 11.4. 21:25 Conscript89 | Brno
Rozbalit Rozbalit vše Re: A fork() in the road
Hehe, to mi zni trosku jako dukaz sporem. Jeste jsem to necetl a je pro me otazkou do jake miry se snazili, ale mozna si sami dokazali ze ho proste v danem systemu (nejake zaklady ktere chteli dodrzet) nelze nahradit necim jinym.

Urcite si to prectu :)
I can only show you the door. You're the one that has to walk through it.
11.4. 11:01 Peter Golis | skóre: 59 | blog: Bežné záležitosti | Bratislava
Rozbalit Rozbalit vše Re: A fork() in the road
A urýchli im to štart Internet explorera (edge), alebo kalkulačky? Na to by sa mali zamerať, a nie na teoretické dohady.
13.4. 00:06 Roman
Rozbalit Rozbalit vše Re: A fork() in the road
Moje rec. Kdyz vidim, jak to maji cim dal vetsi a jak se jim pomalu spousti kalkulacka dyl jak Excel, tak myslim, ze by meli resit spis problemy ve Win32 nez v UNIXech...
11.4. 13:01 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: A fork() in the road
A hlavni duvod je ten, ze se jim fork nelibi, uzivatelum windows ho nepovoluji (ale sami ho interne pouzivaji), ale kdyz chteli udelat novy moderni system, tak jim to neslo bez hromady unixovych nastroju a ty ten fork pouzivaji, takze jejich novy system zacal prilis pripominat unix. Takze fork by se mel zatratit a oznacit za historicky artefakt, aby se ho unix konecne zbavil a udelal to jinak, aby az microsoft bude zkouset udelat novy moderni system a zase se neobejde bez hromady unixovych nastroju, tak mu z noveho moderniho systemu zase nevysel unix...
Conscript89 avatar 11.4. 21:34 Conscript89 | Brno
Rozbalit Rozbalit vše Re: A fork() in the road
Fork is used byalmost every Unix shell,
Ano! A sam taky pomerne casto zamerne pouzivam (source foo; command) nez abych resil nejake dalsi exportovani promennych a vytvareni dalsiho scriptu. Stejne tak se pouziva subshell pro "cat foo | while read line; do; ... done" <=> "cat foo | (while read line; do; ... done)".

Takove veci by se bez forku delaly hodne spatne. A to ani nemluvim o tom kdyz mam subshell se zmenou file deskriptoru 0,1,2
I can only show you the door. You're the one that has to walk through it.
12.4. 06:28 Jardik
Rozbalit Rozbalit vše Re: A fork() in the road
Fork je nadherna vec, jednoduse si muzete presmerovat std vystupy/vstupy, muzete aplikaci predat deskriptor a sdilet ho ... jediny problem je, ze volanim, co vytvari deskriptory musite nastavovat cloexec, nebo alternativu. Melo to byt opacne, I dnes se najdou programy, co cloexec neumi nastavit, nebo pouzivaji alternativu pres fnctl, a pak maji racecondition.
12.4. 12:23 debian+
Rozbalit Rozbalit vše Re: A fork() in the road
cloexec?
12.4. 15:49 Jardík
Rozbalit Rozbalit vše Re: A fork() in the road
Psal jsem to z mobilu, takže to je napsané na rychlo. Flag pro volání open() je O_CLOEXEC. To znamená, že po zavolání exec() se deskriptor automaticky zavře, takže "nově spuštěná" aplikace k němu nemá přístup. Kromě open() jsou ještě další funkce, co vytváří deskriptory a spousta z nich jsou zastaralé a možnost atomicky nastavit tento flag při jeho vytvoření nemají. Většinou existují nové (ale třeba ne-POSIX) verze volaní, které daný nebo podobný flag dovolí nastavit. To je potřeba hlavně u vícevláknových aplikací, kde mezi open() (či podobným voláním) a fnctl() (kde můžeme ono zavření po exec dodatečně nastavit u všech deskriptorů) může zavolat jiné vlákno clone() a nový deskriptor s ještě nenastaveným close-on-exec nám leakne do nového procesu.
12.4. 15:50 Jardík
Rozbalit Rozbalit vše Re: A fork() in the road
clone -> fork, omlouvám se, clone je specifické pro Linux.

Založit nové vláknoNahoru


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