Příspěvky

1291

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 19:30:41 »

Standa B. právě navrhnul ještě lepší řešení než kontrolu. Problem solved.

1292

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 19:28:16 »

Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.

A to prave nestaci. Protoze v te strukture, kterou posilas, muze byt nejaky pointer z te odesilajici goroutiny, a ty o tom vubec nevis (nejaka funkce si tam ulozila neco, cos necekal, ze si tam ulozi).

Jak rika Idris, musel bys kontrolovat cely strom - ne jenom tu horni strukturu, ale i vsechny ji odkazovane struktury.

Pokud budu chtit v danem pripade zamezit tomuto v GO, staci do channelu posilat pointery na hluboke kopie danych struktur a hned je v main threadu zapominat.

K tomu bych dodal: CoW. A je po problému.

1293

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 19:21:18 »

Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.

A to prave nestaci. Protoze v te strukture, kterou posilas, muze byt nejaky pointer z te odesilajici goroutiny, a ty o tom vubec nevis (nejaka funkce si tam ulozila neco, cos necekal, ze si tam ulozi).
Jak rika Idris, musel bys kontrolovat cely strom - ne jenom tu horni strukturu, ale i vsechny ji odkazovane struktury.

Tak ale co ti brání? Si to třeba v jednotkových testech zkontroluj, vždyť to není problém.

1294

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 19:17:44 »

Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny

S tou bezpečností ani blbuvzdornstí bych to nepřeháněl. Stačí si přes channel nevhodně poslat pointer a je na světě problém úplně stejnej jako v C. A vzhledem k tomu, že pointery na structy jsou tak nějak default... Zákeřnější varianta stejné chyby je poslat si sice kopii structu, ale nevšimnout si, že má přes pointer embeddovaný jiný struct. Moc pěkná chyba, hledat ji je čirá extáze

Opravdu blbuvzdornou konkurentnost má Erlang, kde chybu tohodle typu udělat z principu nejde, protože sdílet paměť mezi vlákny ("procesy") prostě nejde a basta I tam samozřejmě pořád zůstává možnost deadlocku.

No to je sice pravda, lec musim s tim pointerem aktivne prasit dale v main threadu.
Pokud pouzivam aspon trochu stabni kulturu, poslu pointer do IN channelu a v main threadu zapominanm na jeho existenci, tam se to bezpecne posle do jedne instance gorutiny (tudiz nenastane situace, ze 2 gorutiny delaji na stejnem pointeru) a vysledny pointer na vysledny gorutinou modifikovany struct nacpu  do OUT channelu, odkud si to v main threadu zase vytahnu.

Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.

Tak jest. Taky v tom nevidím nějaký zásadní problém. Ani nejde IMHO o štábní kulturu, stačí používat mozek.
Na druhou stranu, i přes Prýmkovu hysterii jde o hezký podnět k zamyšlení.

1295

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 17:19:46 »

Z hlavy nevím, ale můžu zkusit něco najít o “obvyklých podezřelých” (například Cheney apod.). Stay tuned

Jezkovanoho, nedelej z toho vedu. Ukazal jsem problematicky priklad na par radku. Pokud jde nejak opravit, tak to bude oprava na par radku. Tak shut up and show the code

Tohle nebylo na tebe.

1296

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 17:18:58 »

Ať už k tomu zdroják máš nebo ne, místo (abych použil tvou terminologii) pindání si to kontroluj za běhu (třeba asercí), pak ti to bude fungovat i s knihovnami nebo pluginy třetích stran a pokud rozumně testuješ, k zákazníkovi se taková chyba nedostane.

BTW ta kniha je fakt dobrá, protože se nezaměřuje úzce jen na technické věci, ale právě i na testování a jiné užitečné postupy. Prozřel bys. Možná. Doufám.

1297

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 17:03:36 »

Nevím, co si představuješ pod "kontrolovat kompozici objektů".
Chci, aby na mě překladač zařval,

To, cos napsal, zjistit, jestli někde v hloubi objektového grafu není ukazatel.
Akorát už měníš “zadání”, nejdřív píšeš “není možné”, a pak “chci, aby překladač zařval”. To není totéž. Nejdříve si přečti *pozorně* tu knihu. Pak se nauč vyjadřovat přesně. No a pak si můžeme zase popovídat

P.S. A ano, bylo by mnohem lepší, kdyby Go (a vůbec všechny jazyky s kompozitními typy) mělo u polí modifikátor “initonly”, ubylo by blábolů prvotních i blábolů reagujících na bláboly

Nenašel by se nějaký příklad, co není za paywallem?

Z hlavy nevím, ale můžu zkusit něco najít o “obvyklých podezřelých” (například Cheney apod.). Stay tuned

1298

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 16:55:07 »

Nevím, co si představuješ pod "kontrolovat kompozici objektů".
Chci, aby na mě překladač zařval,

To, cos napsal, zjistit, jestli někde v hloubi objektového grafu není ukazatel.
Akorát už měníš “zadání”, nejdřív píšeš “není možné”, a pak “chci, aby překladač zařval”. To není totéž. Nejdříve si přečti *pozorně* tu knihu. Pak se nauč vyjadřovat přesně. No a pak si můžeme zase popovídat

P.S. A ano, bylo by mnohem lepší, kdyby Go (a vůbec všechny jazyky s kompozitními typy) mělo u polí modifikátor “initonly”, ubylo by blábolů prvotních i blábolů reagujících na bláboly

1299

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 16:16:45 »

A proto, milé děti, nepraste a sdílejte jen immutable objekty.

jenze imutabilita nejde v Go [...] zkontrolovat.
Takze v Go proste zadny dobry reseni nemas. [...] ze struct neobsahuje (na jakekoliv urovni!) zadny pointer nezkontrolujes

Nic z toho není pravda, kontrolovat kompozici objektů jde a dokonce se to v částech standardní knihovny využívá. Donovan a Kernighan mají v knize “The Go programming language” příklady.

1300

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 16:00:59 »

A proto, milé děti, nepraste a sdílejte jen immutable objekty.

To je sice dobra rada a radostne bych souhlasil, jenze imutabilita nejde v Go vynutit a dokonce ani zkontrolovat.

Takze v Go proste zadny dobry reseni nemas. Imutabilitu nevynutis, ze struct neobsahuje (na jakekoliv urovni!) zadny pointer nezkontrolujes a jediny, co ti zustane, jsou neopodstatnena velkolepa prohlaseni, ze kanaly jsou "bezpecne a blbuvzdorne", pricemz nejsou ani jedno, protoze narozdil od Erlangu v gocku implementovali CSP ponekud nedomrle. O cemz se ale nesmi mluvit, protoze Go je dokonale ve sve jednoduchosti

Tolik k alternativní realitě. Skutečnost je, že se to všeobecně ví a ty si jen s velkým kraválem myslíš, žes objevil Ameriku

1301

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 14:40:17 »

Takova mensi ilustrace:

https://play.golang.org/p/jjbq2b4NyI0

Kdyz si predstavim, ze obsah A a B je nedokumentovany a ja pisu jenom consumer(), asi budu hodne kroutit hlavou, co delam spatne...

A proto, milé děti, nepraste a sdílejte jen immutable objekty.

1302

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 13:24:27 »

Jak "nevhodně"? Když vytvořím objekt a pak ukazatel na něj pošlu kanálem, tak příjemce s ním může normálně pracovat a GC ho nechá na pokoji, dokud na něj existují odkazy (když je v bufferu, tak do uzavření kanálu).

No právě. Vytvořím tak shared memory úplně stejně jako v C, se všema nebezpečíma, který to v C má. Žádná větší "bezpečnost" se v takovým případě neděje. Čili "blbuvzdorný" to moc není, dají se tam velice snadno udělat stejný průsery jako v C.

A co když ten odkazovaný objekt je immutable?

1303

Vývoj / Re:Práce s vlákny v C

« kdy: 25. 01. 2021, 13:07:46 »

Stačí si přes channel nevhodně poslat pointer a je na světě problém úplně stejnej jako v C.

Jak "nevhodně"? Když vytvořím objekt a pak ukazatel na něj pošlu kanálem, tak příjemce s ním může normálně pracovat a GC ho nechá na pokoji, dokud na něj existují odkazy (když je v bufferu, tak do uzavření kanálu).

1304

Studium a uplatnění / Re:Zlepšení jazykových dovedností

« kdy: 20. 01. 2021, 10:39:29 »

Mně se osvědčily podcasty, poslouchám ty na Irish times (většinou World View, neb irská politika mě zas až tak nezajímá). Jinak ty dialekty jsou někde v pohodě a někde fakt strašné: https://www.youtube.com/watch/pit0OkNp7s8

1305

Vývoj / Re:Práce s vlákny v C

« kdy: 20. 01. 2021, 04:02:52 »

Mimo puvodni dotaz.
Multithreading v C je pain a porad jednou nohou v pruseru. Business kod taky pain, prenositelnost a devops peklo.
A to nejenom pri vyvoji ale hlavne dale pri zmenovkach a udrzbe.
Neznam samozrejme pozadi tohoto programu, ale zvazil bych pouziti vhodnejsiho jazyka.

Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny
Nebo v Jave pri pouziti netty.io

Pthreads jsou “pain”, v C je vždy lepší použít Grand Central Dispatch (což je pro BSD, Linux i Windows). V C++ pak existují další vhodné knihovny.