clojureでのref実装について（中編） - marblejediary
全後半で分けようかと思ったのですが、想像していたより複雑な内容なので、tokyoclj3では整理しきれませんでした。ということで、refの内部構造とトランザクションのアボートを考慮しないref-setでのrefのオブジェクトツリーの状態遷移を整理してみます。 次回tokyoclj4あたりで、もう一歩踏み込んでコードを読んでみようかと思います。ポイントを使用した平行性制御についてはまだ完全に整理できていないので、一部説明が逃げ腰です。また、間違いがあればご指摘ください。 僕は構造からつかみにいくタイプなので、関連を整理してクラス図を書いてみました。 ソースにコメントがないので責務を推測します（余談ですが、java.util.concurrent下のコードはコメントが詳しく書いてあったり、実装根拠の論文へのリンクがあったりするので、面白いです）。 ◆ Ref STMのトランザクション内で変更可
clojureでのrefの実装について（前半） - marblejediary
今日はtokyoclj#3なので、前回に引き続きclojureでの平行性実装についてみています。 前回もjavaの実装はチラ見していたのですが、clojure側の実装をみていなかったので、機能の復習もかねて整理しておきます。 clojureはjavaでSTMを実装しています。java.util.concurrent.*が大活躍です。なので、clojure側の実装はあまりみても重要ではないのですが、機能を整理しておきたいのでちゃんと読んでみました。 refというのはSTMで扱うことができるオブジェクトです。STMというのはsoftware transactional memoryのことです。ロックフリーなセマンティクスで、複数の処理をatomicにできる、便利なものです。平行処理がロックフリーであるということは、複数のロックを使用して平行性を高めるとか、難しいアルゴリズムをつかうとかしなくて
非同期なDatastoreService的なものとかつくってみた - marblejediary
うーん。結構悩ましいのですが、ノリと勢いでつくってみました。最近ブログさぼりがちだったので、ネタが欲しかったともいうかも。 #appnegineでは、api呼び出しをRPCで実装していて、すべてのサービス呼び出しはApiProxy.makeSyncCallを通って他ノードと通信を行っています。実はApiProxyにはmakeAsyncCallというのもあって、他ノードとの通信を非同期で行うこともできるようになってます。 この辺は、 http://d.hatena.ne.jp/marblejenka/20091125/1259169026 http://d.hatena.ne.jp/marblejenka/20091129/1259519548 http://d.hatena.ne.jp/marblejenka/20091204/1259941582 などを参照していただければ。 で、このm
scalaからappengineのapiをたたくシェルがようやくできたっぽい - marblejediary
普通にスクリプトからたたくのは発火村のときにいけてたのですがね。 やっぱり対話的なのがいいでしょうと（元の目論みではそうじゃないと意味ない）。 なんとなくInterpreterLoopかなぁ、と思ったのが正解っぽかった。こちらのエントリを参考にさせてもらいつつつ、jar追加するのどうやるのか、どう見てもsettingsをどうにかすればいいんだけれど。。とか思いつつ、なんやかんやでこんな感じです。 #!/bin/sh exec scala "$0" "$@" !# class AppengineRemoteCallableInterpreterLoop(out : PrintWriter) extends InterpreterLoop(None, out) { override val prompt = "scala-appengine>" override def bindSetting
TaskQueu実行の仕組み - marblejediary
ApiProxyをほげるのが面白そうなので、まずは中身をいろいろ想像してみることから始める。taskqueueメインでやっている人はあまりいなさそうなので、人の行く裏に道あり花の道、の思想で。 前の絵はApiProxyの呼び出しよりしたを中心に、こちらの11p周辺を参考に書いたものです。サービス呼び出しまでのいろんな箇所をほげっておれおれQueueみたいなものを作りたいので、今度はサービスが呼び出されるまでのところを追いかけてみました。 基本的には、datatoreなどのサービスと内部的な構造はかわらないようです。taskqueueだけ、labパッケージにきられているので特殊な構造をしているのかと思ったのですが。 DataStroeとの対比では、DataStroeService/implと言われているものがQueueFactory/Queueとそのimplで置き換えられていること、Prot
1.3.1 SDK Prerelease!! lower level apiの動向 - marblejediary
この時間でも、お家が会社に近いんで間に合うんですよ。いいでしょ。 ということで、1.3.1 SDK Prereleaseです。 lower level apiの変更について簡単に調べたので、下記に掲載します。動作確認はまだなので、あくまで変更されているという事実だけですね。 ご参考までに、すべてのlower level apiの変更点について、リリースノートには記載されていません。lower level apiは、googleの内部のサービス基盤に接続するインターフェイスであると考えることができ、将来的な変更を予測するにはよいポイントだと思います。 変更点は下記の通りです。 ・blobstore.DecodeBlobKey なんだろ？よくわかりません。httpのrequest/responseにblobのkeyがのっけられるってこと？そういうのってできなかったの？ ・datastore_v
appengineのjunitテストを実行環境によって動かしたり動かさなかったりしたい - marblejediary
うーん。いろいろ悩ましいのですがとりあえず書いておこうと思います。 production環境でのテストには、@bufferings氏のkotoriが使えるので、便利です。 便利ですが、僕の作っているbalmysundaycandyというものでは、low level apiが隠蔽しているappengineの割と中のほうの隠れapi的なものを使うようにするぜ！というもので、環境によって動いたり動かなかったりということがあります。 例えば、datastore_v3#GetSchemeは、開発環境では動作しますが、プロダクション環境では動作しません。こういう隠れapiでなくても、例えば、kindless ancestor queryと呼ばれているクエリは、プロダクション環境では動作しますが開発環境では動作しません。これについては、@shin1ogawaさんの解決方法があるので、まぁどうにかできる問
#ajn3に参加しました！ - marblejediary
発表者・参加者の皆さん、おつかれさまでした。 個人的にメモった部分だけですが、まとめておこうと思います。 発言者が入り乱れているところがあれですが、セッションごとのまとめとしてみてもらえればと思います。 キムティ♪さんによるtwitterのまとめ http://d.hatena.ne.jp/kazuki-aranami/20091204/1259938454 【あおうささん】資料はこちら：http://d.hatena.ne.jp/bluerabbit/20091204 テーマ：「実際に作ってわかったappengineの困ったところ」 ・TaskQueueをチェインして実行することができるし、そうすれば30秒の境界を越えられる ・チェインする場合、チェイン先にどうやってデータを引き渡すかが課題。datastoreやmemcacheを使う場合、並列実行されることを考慮する必要がある ・Mem
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
clojureでのref実装について（今後の課題編） - marblejediary
clojureでのref実装について（後編） - marblejediary
clojureでのref実装について（メモ編） - marblejediary
balmysundaycandy-scala betaをリリースしました！ - marblejediary
Scala Hack-a-thon #2 に行ってきました - marblejediary
DSL駆動開発×AppEngine @asami224 先生 - marblejediary
App Engine Transaction Puzzler @ashigeru さん - marblejediary
#ajn3おつかれさまでした！そしてmakeAsyncCallはどうなのか！？ - marblejediary