channelとsync.Poolを使ってgoroutine内の処理の同時実行数を制御する - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Big Sky :: 簡単に goroutine の実行個数を制限する方法
Go は簡単に軽量スレッドが起動できるのがウリなのだけど、その使い方が難しいと思われているきらいがある。 Goへの誤解について - GolangRdyJp よくGoで誤解されるポイントについて個人的な見解を書いておきます。 今回の記事は Goアドベントカレンダー2017 その3 の20日目の記事です。 使ってないパッケージがコンパイルエラーって面倒じゃね... http://golang.rdy.jp/2017/12/20/go-fact/ 慣れていない間は、処理を並行化する際に「どうやったら並行化できるんだ」が分からない事があるのだと思う。 Big Sky :: golang の channel を使ったテクニックあれこれ golang の channel は他の言語に見ない独特のパラダイムを開発者に提供します。 単純にスレッド間でメッセージングをするだけでもC言語で書けばそこそこの量に
本番導入出来なかったけどGoでちょっと早いfluent-loggerを作った時の話
この記事はGo4 Advent Calendar 2017の12/15のエントリです。 Go2 Advent Calendar 2017の１日目の記事で、go-fluent-clientの紹介 という lestrrat さんの投稿があり、そういえば今年の初めに転職やら色々あって導入までは出来なかった Go の fluent-logger 作ったなということを思い出したので、当時どんな感じで作っていたかを踏まえて簡単に紹介してみようと思います。 daichirata/fluent-logger-go 元のコードに関しては導入しないと決めた時にとりあえずファイルだけ Github に上げてるだけの状態だったので一旦別ブランチに退避して、今回は当時を再現しつつ１からコミットし直してみたいと思います。 そもそもなんでわざわざ作ったかというと、最近は Go をそもそもあまり触っていないので当時と同じ
Goroutineハンターが過労死する前に - Qiita
Goroutineハンター、それは逃げ出したgoroutine達を捕まえるため、日夜戦い続けるエンジニア達のことである。Goroutineハンターは本番環境でOOM Killerが発動するたびに呼び出され、逃げ出したすべてのgoroutineを捕まえるまで家にかえることが出来ない。しかし、あなたが書いた何気ないコードによって、今日もまた新しいgorutine達が野に放たれるのであった。 Goroutineリークとの戦い Goを使用してある程度規模のプログラムを書くと、必ず問題になるのがgoroutineのリークである。goで生まれたgoroutineが、何らかの理由で正常に終了しない場合、それは「リーク」していると見なされる。リークしたgoroutineはプロセスが続く限り永遠にリソースを手放さないため、リークしたgoroutineが蓄積するに従って、プログラムのパフォーマンスは低下してい
goroutineがスイッチされるタイミング - Qiita
goroutineがスイッチされるタイミングについて調べていました。 結論 Go言語で、goroutineは 必ずしも スイッチされるわけではない。 スタックに触れないような、「for(){}」みたいなビジーループをGOMAXPROCSの指定数以上に含ませるとスイッチされなくなる。 goroutineがスイッチされる(主な)条件はこれらと思われる。 - goroutineの関数が最適化でinline化されていない - スタックを操作するような処理を行った - (その他の契機もあるようなので「経緯」で書く) 経緯 処理のないビジーループが有ると、goroutineがスイッチされず処理が止まることに気づきました。 ＃ 処理の中身を全部コメントアウトしてデバッグしていたら気づいた package main func busy() { for { } } func main() { go busy
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点 - Qiita
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
Go Conference 2014 spring で発表してきた
5月31日にGoConference 2014 springというイベントで pt & Goroutine というタイトルの発表をさせてもらいました。 今年に入ってから Go言語をさわるようになって、pt(The Platinum Seacher)というGoでつくったagライクな高速検索ツールを公開しており、そこからのつながりで今回の発表となりました。 内容的には、以下のスライドのとおり、同ツールの高速化の経緯をたどりながらGo言語の並行処理を実現する機構であるGoroutineの使い方を知ってもらうという構成でした。 TLの反応などを見ると、需要はあり一定の満足はもらえたんじゃないかなとほっとしています。 200名ぐらいの参加者がいて、海外からのスピーカー来ているという今回のカンファレンスは、福岡から参加した自分にとってはなかなか本格的なもので、たくさん刺激を受けたし、こういうところで話
Goroutine Synchronization : D-7 <altijd in beweging>
（以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません） これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。 TL;DR; goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。 deferの基本 goではLLのノリでコードを書けるのが売りの一つですが、メモリ管理はしてくれるものの、様々なリソース解放も全て自動というわけではあり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go Concurrency Patterns: Pipelines and cancellation - The Go Programming Language