本番導入出来なかったけど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 をそもそもあまり触っていないので当時と同じ
並列/並行基礎勉強会でasync/awaitをDisってきた - ぐるぐる～
async/await不要論 from bleis tift 3/23 に開催された、並列/並行基礎勉強会で「async/await 不要論」という発表をしてきました。 一番言いたかったこと 一番言いたかったことは、実は並列とかとは全く関係ないことです。 それは、言語への機能追加に関することです。 C# は 5.0 で非同期処理のための専用の構文として、async/await を導入しました。 これは、F# が計算一般という抽象度の高いものための汎用的な構文として、コンピュテーション式を採用しているのとは対照的です。 専用の構文を用意するかしないかは、その言語を取り巻く環境次第です。 専用の構文の利点と欠点 専用の構文の利点は、その使用用途が明確であるというところにあります。 そのため、書き方さえ覚えてしまえば、その裏で何がどうなるかなどを一切気にせずに使えてしまえたりします。 欠点は、専
node.jsのいろいろなモジュール17 – asyncで非同期処理のフロー制御 | DevelopersIO
node.jsでの関数呼び出し 非同期処理 node.jsはnon-blocking処理を行うため、関数によってはプログラマの意図しない順番で処理が実行されることがあります。 次の例をみてください。プログラムの開始をconsole.logで出力後、ファイルを読み込んで内容を出力、 最後にプログラム終了をconsoke.logで出力しています。 //app.js var fs = require('fs'); console.log("start"); //ファイル読み込み fs.readFile("hello.txt","utf-8",function(err,data) { console.log(data); }); console.log("finish"); 上記プログラムを自分の環境で実行した結果は次のようになってます。 startとfinishが表示され、ファイル内容は最後に表
Async小話(末尾再帰関数) - pocketberserkerの爆走
過去にTomas Petricekさんの非同期に関する記事を翻訳しました。 Async in C# and F#: Asynchronous gotchas in C# (Japanese translation) この記事の最後には以下の記述が存在します。 また、F# の async も問題を持っています（最も一般的な落とし穴は、末尾再帰関数はリークを避けるために do! の代わりに return! を使うべきだということです）。 まずは試してみよう 簡単なサンプルコードで試してみましょう。 open System let rec loop x = async { do! if x < 1 then async { return () } else loop x } loop Int32.MaxValue |> Async.Start このコードはおそらく OutOfMemoryExce
Wait for response with timeout in "Dispatch" library
I am going to use Dispatch to write a simple HTTP client. I call dispatch.Http to get a future and call the future to get the response val request = ... val future = Http(request) // call the server asynchronously val response = future() // wait for the response from the server Now I wonder how I can wait with timeout. I would like the last API call to be: // throw an exception if no response rece
非同期メソッド入門 - xin9le.net
.NET Framework 4.5 / C# 5.0 から提供された非同期メソッドについての連載インデックス インデックス 非同期処理の歴史 非同期メソッドの概要 async修飾子とawait演算子 任意の記述場所 UIスレッドとの同期 戻り値 例外処理 非同期メソッドの内部実装 内部実装を覗く コンパイラ要件 Awaitableパターンの自前実装 WinRTとの相互運用 Rxとの相互運用 落ち穂拾い NET Framework 4.5以外でawaitする コンパイラ要件違反 単体テストの記述方法 機械的読み替えに注意 非同期勉強会 / Community Open Day 2012 その他の資料/動画 非同期勉強会 資料 Community Open Day 2012 資料 Three Essential Tips for Async @ITでの連載
openのO_ASYNCフラグ - Linuxの備忘録とか・・・(目次へ）
openのオプションにO_ASYNCと言うのがあり、説明によると、シグナル駆動 I/O (signal-driven I/O) を有効にする: このファイルディスクリプタへの 入力または出力が可能になった場合に、シグナルを生成する。と言う事。が、現行バージョンではサポートされなくなった模様(別の機能として何かあるのかもしれませんが・・・） 以下はopen/fcntlのO_ASYNCフラグの検証したものです。コマンド引数にて３通りの条件の実行結果で、それぞれ実行毎に、別端末からecho a > /tmp/fasynceとし、パイプに書き込みしています。 #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <signal.h> int fd; void sigio(int
Rubyの並行処理で学んだこと――パート１(翻訳版) - Engine Yard Blog JP | Engine Yard Blog JP
この記事は英語版のブログで2013年2月5日に公開された記事の翻訳版です。 Engine Yard のPaaS製品は非常に複雑である上に、数千ものサーバーに及んでいます。弊社のアプリケーションを素早く確実に動作させるには、並行処理と並列処理をよく理解する必要があります。私は、自らの開発努力でこの問題を解決しようと、並行処理という困難な世界を探求しました。この投稿はその要約です。後編となるパート2では、並列処理に重点を置いて説明する予定です。 ハードウェア？ この問題をハードウェアで解決しようとすることはできます。しかし、CPUがネックなのであれば、コアごとのスピードをある程度まで上げることはできても、最終的には役に立たなくなってしまいます。サーバーの数を増やすにしても、同じことが言えます。次々とシリアル処理を行っても、追加されたサーバーごとの処理装置の数は決まっているからです。 「シリアル
非同期処理の基礎
MPAなWebフレームワーク、Astroの紹介 (その1) 2024/05/17の勉強会で発表されたものです。
DBD::mysql の async について - tokuhirom's blog
並列にバンバン処理するかっこいい機能がついたわけではなく、だいぶアドホックな実装になっている。 mysql client として考えた場合に処理が遅いのは、DB サーバーの I/O や集計処理で、データを返しはじめてからの処理は速い、という経験則にもとづいた処理となっている。 request をなげておいて、sock を poll しておき、readable になったら blocking I/O で普通に読む。mysql server は返しはじめたら一気に書くので、読みはじめたら一気によんでも問題がない。という実装依存のコードになっている。 という感じの実装になってるので、一般的な実装とだいぶちがうので、普通の実装だとおもって読んでると混乱する。 【201402181531 追記】 「select * from t みたいなケースだと、i/o bound でダラダラデータが返ってくる」と
Asynchronous MySQL Queries in Perl Using DBD::mysql and AnyEvent | hoelzro [blogs.perl.org]
A lot of people use MySQL, and these days, asynchronous-style programming has really taken off. If you're involved in both of these camps, you may be wondering how to send a query to MySQL and have it inform your event loop when it's ready with the results of that query. A common solution is to use a thread or child process for each connection, and exchange data using IPC. However, if you're using
aleph/lamina: Clojureでサーバー/クライアントWebSocket - Qiita
2013年のClojure界隈はcore.asyncが話題ですが、今回は非同期処理にcore.asyncは使いません。 今回はcore.asyncの代わりにalephというライブラリを使って、WebSocketを使った簡単なデモアプリケーションを作ってみようと思います。サーバーとクライアントの両方をClojureで実装します。 alephは、同じ作者のlaminaという非同期プログラミングライブラリをベースに、nettyを使ってHTTP/WebSocket/TCP/UDPのI/Oをサポートしたライブラリです。 core.asyncと同様に、laminaではchannelと呼ばれるキューにメッセージを出し入れすることで非同期処理をサポートしています。 laminaにはchannel以外にも様々な機能がありますが、今回はchannel以外の機能は使わないので解説しません。(というか解説できるほ
Linuxの非同期I/Oについて - takkan_mのNo planな日常
最近、LinuxのI/Oまわりについて調べていた延長で、ちょうど一年ぐらい前にlighttpdの1.5が採用して性能があがったといわれた、非同期I/Oまわりについて調べてみたので、これから現状自分がわかっている範囲でのまとめと疑問点を書いてみます。ひとつのエントリに書いてしまうと、ものすごく長くなりそうなので、linux_aioというタグをつけていきます。 というわけで、よくわかっていない部分もあるので、間違い等あれば指摘いただけると、うれしいです。 LinuxのI/Oは同期？非同期？ 2007-10-13 なぜ非同期I/OのAPIが存在するのか 2007-10-13 POSIX準拠の非同期I/O 2007-10-13 2007-10-15 - takkan_mのNo planな日常 2007-10-15 どうやってI/Oの完了をうけとっているか（準備編） - takkan_mのNo pl
並列1000コネクションに耐える！ Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋
並列1000コネクションに耐える！ Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント こんにちは、takada-at です。 Rubyのイベント駆動型ネットワークプログラミングフレームワーク Rev と EventMachine で HTTPクライアントを動かしてみました。 イベント駆動型ネットワークプログラミングフレームワークとは何か説明しだすと難しいですが、一言で言うと、以下のようになります。 # ふつうのフロー駆動型プログラム Net::HTTP.start(host, port){|http| res = http.get(path) #この処理が終わってから } puts "done" #この次の処理が実行される # イベント駆動型プログラム client = Rev::HttpClient::connect(host, port
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ParseがRubyからGoへ移行，信頼性が大きく向上
Charming Python: Functional programming in Python, Part 3