高速なキューを作る話（後編） - Qiita
前編の続きです。前編ではChan.Unagiには以下の欠点があることを解説しました。 読み出しを行うスレッドに対する非同期例外の扱いが面倒 データがすぐにGCされない 後編では、Chan.Unagiの欠点を克服したキューを作るやり方について解説します。 不要になったデータをGCできるようにする まずは簡単な方から解決していきましょう。 Chan.Unagiで読み出し終わったデータをMutableArrayから削除できないのは、Chan.Unagiがチャネル（書き込まれた値を複数のキューに書き込まれたかのように読み出す機能を持つ）であるためでした。 であるならば話は単純です。作りたいのはチャネルではなくキューなのでデータを削除すればよいのです。 具体的には、MutableArrayに入れるデータ型の定義に読み出し終わった状態を追加し、読み出し処理の終わりに、この値を書き込めば解決です。 この
高速なキューを作る話（前編） - Qiita
私が以前Haskellで作成した（割と自己満足な）kazura-queueという比較的高速なキューのライブラリがあります。 このライブラリを作るときに考えたアレコレを書いてみたいと思います。 前提 ここでいうキューって何？ データ構造としてのキュー（Sequenceみたいな）や分散処理用のキュー？（RabbitMQみたいな）ではなく、並行処理のためにスレッド間の部品として使うようなキュー（Chan（やTQueueやTChan）みたいな）を意図しています。 ここではChanが持っているキューとしての性質をざっと書き出してみましょう。 キューに入るデータの型は任意 Chan aという型で表現できる範囲で好きなデータを入れることができる。 FIFO キューなのだから当たり前といえば当たり前かもしれませんが一応。 スレッドセーフ 複数のスレッドが同時に書き込もうとしても問題が起きない。1 複数のス
FRPNowをサーバで使ってみた - Qiita
この記事は ACCESS Advent Calendar 2015 19日目の記事です。 ACCESSの @asukamirai です。 FRP（Functional reactive programming）をサーバのロジックとして使うのはどうなのだろう、ということで試しに感覚を掴むためにやってみました。 使用したFRPのライブラリは、ICFP2015に登場した論文のFRPNow。言語はHaskellです。 確認環境など stack 0.1.10.1 lts-3.18 frpnow-0.18 OS: Windows7 64bit 動機 FRPというと、なんとなくGUI的なものを扱うようなイメージが強かったのですが、その一方で、データフローでプログラミングを行うというのは、ストリーミング処理系のライブラリとも共通する部分がありそうだと思っていました。 先月行われた関数型ストリーム処理勉強会
stack経由でghcをインストール（ubuntu） - Qiita
haskellの強力なビルドツールstackがリリースされました。 stackにはghcをインストールする機能もあるので、これを使えばhaskell-platformを使うよりもghcを使える環境を整えるのが楽かもしれません。 というわけで、ghcなど、haskell関連の準備が全くない状態から、stackを使ってghcをインストールする手順をまとめました（といっても大したことはしていませんが）。 環境・バージョンなど stack-0.1 ghc-7.8.4, 7.10.1 OS: lubuntu 15.04 64bit インストールするghcは7.8.4です。 7.10.1もインストールできましたが、現状ではstackのデフォルトは7.8.4のようなので7.8.4にしています。 cabal-installについて stackは強力なツールになりそうですが、まだまだcabal-instal
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
