Goでchannelがcloseしてるかどうか知りたい というアンチパターン

そういえば金沢に行って来た話の2〜4日目をかいてる途中で2ヶ月くらい経ったことに気付きましたが、まぁその話はおいておいて今日はGoの話です。 さて、このタイトルを見てGoに詳しく賢明な読者の方々は「あぁまたこの話題だよ、Goでchannelがcloseしてるかどうか知りたいようなパターンはだいたい書いてるアプリの設計とかchannelの使い方が間違ってるんだからやめとけ」と眉をひそめるかもしれません。まぁちょっとまって! オレもそうなんじゃないかなぁという気はしているし、ハマリどころがありそうということはうすうす分かってるけど一応調べて考えてみてもいいじゃないか。 結局の所調べて「こうすればいいね!」ってことは分かったんですが、それも破綻する場合があるので、アンチパターンだなぁと思いつつこの記事を書くことにしました。 まずGoのchannelのナイーブさを再確認する そもそもGoのchan

[castaneai]

“Goでchannelをcloseしてるかどうかを気にする設計はヤバイ徴候 closeする必要があるときは1回だけ確実にcloseするように設計しよう”

[issyurn]

“もちろん、アプリの実装者としてはchannelのcloseチェックをしてcloseする、という場所を全部mutexで保護してchannelのclose処理をアトミックにやるということは理論上可能です。可能ですが、正直そんなことやりたくないしそ

[otiai10]

“Goでchannelをcloseしてるかどうかを気にする設計はヤバイ徴候”

[sexmachinegunmu]

Goでchannelがcloseしてるかどうか知りたい というアンチパターン - https://t.co/pcAC4n3kMo

[shag]

英語の naive て意味違うような気がするけどコンピュータ・サイエンス的に正しい使い方だったりするんだっけか？sensitive で良い気が(とかどうでもいい

[muddydixon]

ナイーブ

[mandel59]

Rustは解放後使用の問題を解決するために複雑な型システムを導入した。一方Goは鉛筆を使った。

[kwhrtsk]

ビンカン過ぎる……

[kasumani]

Goでchannelがcloseしてるかどうか知りたい というアンチパターン そういえば金沢に行って来た話の2〜4日目をかいてる途中で2ヶ月くらい経ったことに気付きましたが、まぁその話はおいておいて今日はGoの話です。 Tags: from Poc

[atsushifx]

[I/O][Concurrent Programming][並列並行プログラミン]channelってなにかと思ったら、Goでのデータ入出力のための仕組みなのね。ならcloseを外すのは納得。並列・並行プログラミングだから、そういったリソースはOSかコンパイラで吸収するってこと

[ledsun]

ふむふむ。難しげ

[cubicdaiya]

別件だけどゴルーチンがリークしてるか知りたいときがあって、デーモンだとメモリリークと変わらないので検知する仕組みがほしい

[honeybe]

「使い方ミスるとスペランカーばりによく死ぬ」

[kenjiskywalker]

すげぇ... 思春期の男子中学生ぐらいナイーブだ..

[sonots]

hmhm

[lestrrat]

エラーになっても取りあえずプログラム落としたくない、ってだけだったらrecover使うというてもある