ひさしぶりにはまった…。

コーダーならば、たった一文字の違い == が = になっていた…という類の超くだらないバグに丸１日を費した経験があると思います。PHP Extension の記事を書いていて、SegFault で落ちる不可解なバグに昨日の晩から悩まされました。
手がかりは

PHP Warning:  Function registration failed - duplicate name - __construct

まぁ、冷静に考えてみよう。ダブル・アンダースコアやアンダースコアから始まる名前は使ってはいけなかったのだ。そんな事は百も承知だった。参考にしたURLのコードが、このような関数名を使っており、一個目に作成した PHP Extension がこれで、動いてしまったもんだから、これが流儀だと思い込んでしまったのだ。関数名がバッティングしていて、PHP_METHOD の定義がへたれなんだろうと思って調べてみたけど

#define ZEND_METHOD(classname, name) ZEND_NAMED_FUNCTION(ZEND_MN(classname##_##name))

と、ちゃんと処理してるっぽい感じです。ともかく、コンストラクタの名前を正規の名前に変更したら、動作するようになりました。PHP Extension を書くにあたって、ありきたりのクラス名と、ありきたりのメンバ関数名の組み合わせは、御法度なのかもしれません。

追記：コンストラクタがコールできへんやんけーわりゃーーーーなめとんのかーーー
追記：現在進行形　nm コマンドで、関数エントリを調べてみたが、マクロの意図通りの関数名に展開されていた。これは、まったく違うところではまっているに違いない…。
追記：gdb で調べてみたが、登録処理でまともに成功しなかったため、モジュール・アンロード時の処理でSegFaultしていた。ちゃんと登録処理のところを重点的にステップ実行しないとダメそうだ。本腰を入れてgdbの勉強もしないとダメだこりゃ…。
追記 2012/01/09: 引数ありのコンストラクタと引数無しのコンストラクタで関数名が異なるのが原因だと推察しているが、放置プレー。Cベースで記述されていると、こういう問題にぶち当たる。

HIPHOPって…

　PHPのExtensionを書いている時にFaceBookがPHPのコードをC++で移植しているという話を読んだ。ああ、彼らもExtensionか？さもありなん…。なんて思ってたけど、全然違うやんけーーーー。HIPHOP
　これは変人のやる領域のような気がしてならない。構文は似てるけどさ…。なんか、コンバートがうまくいくかどうかは、「おみくじ」みたいで恐いなぁ。もしかして、PHPでExtension開発なんて、大半の人には不要になったかな？バッファ・オーバーランとか、C++は、馬鹿と鋏は使いようで超恐ぇよ。

LockTest ふたたび

　LockTest ふたたび・・・なんて言われても、知らねーよ・・・だと思いますが、ブログをはじめる前にアップしていたもので、Intel TBB の reader_writer_lock が、どれほどのものかテストしてみました。
使ったのは、TBB バージョン３です。

#include <tbb/reader_writer_lock.h>

...

tbb:interface5::reader_writer_lock rwl;

// 書き手ロック
rwl.lock();
// アンロック
rwl.unlock();
// 読み手ロック
rwl.lock_read();
// アンロック
rwl.unlock();

というような使い方です。

　サンプル・プログラムは、VC8 の MFC を使って作成しました。



縦１列がスレッドになります。上から状態を表し、

1. ニュートラル
2. リーダーロック初期
3. リーダーロック・ロック待ち状態
4. リーダーロック・ロック獲得状態
5. ライターロック・ロック獲得状態
6. ライターロック・ロック待ち状態
7. ライターロック初期

となっています。

　

　どのクラスを使うか？の指定は、LockTestView.h で変更できます。

// BOOST read_write_mutex を利用する場合は下記をコメントアウト
// boost::thread は、ライブラリを構築する必要アリ
//#define BOOST_RW
//#define TBB_RW 1

#ifdef BOOST_RW
#include <boost/thread/shared_mutex.hpp>
#elif TBB_RW
#include <tbb/reader_writer_lock.h>
#endif

#define BOOST_RW のコメントを外せば、boost の shared_mutex を利用します。こちらの特徴は、読み手が優先だったように思います。記憶があいまいですが、リエントラント（再入可能）だったと思います。

#define TBB_RW のコメントを外せば、Intel TBB の reader_writer_lock を利用します。こちらの特徴は、書き手優先です。スピン・ロックを利用しているので、軽量なのが特徴です。たくさんの書き手が発生しない状況では、有用です。ほとんどのアプリケーションで、このクラスは活用できるのではないでしょうか？パッと見た感じ、リエントラントではありません。

何もコメントアウトしないと、私の書いたものが利用されます。Windows 限定で、ミューテックス・セマフォとゴージャスなので重量級と言えます。もちろんリエントラントではありません。特徴は、スタベーションを起こさないようにしています。

　初期状態では、

// ランダムに読書をリクエストするスレッド数
#define  THREAD_RANDOM_COUNT   20
// 読込みばかりをリクエストするスレッド数
#define  THREAD_READONLY_COUNT 5
//#define  THREAD_READONLY_COUNT 0
// 書込みばかりをリクエストするスレッド数
#define  THREAD_WRITEONLY_COUNT 5
//#define  THREAD_WRITEONLY_COUNT 0

かなり厳しい条件（スタベーションが起こる）ですので、

// ランダムに読書をリクエストするスレッド数
#define  THREAD_RANDOM_COUNT   20
// 読込みばかりをリクエストするスレッド数
//#define  THREAD_READONLY_COUNT 5
#define  THREAD_READONLY_COUNT 0
// 書込みばかりをリクエストするスレッド数
//#define  THREAD_WRITEONLY_COUNT 5
#define  THREAD_WRITEONLY_COUNT 0

と、書き換えてテストしてみて下さい。

　include, lib の設定は、自分の環境に合わせて設定しないとコンパイルできません。ソースは、MySkyDrive からどうぞ（ブログのパーツから）

書の未来

　フリーにも書かれていたように、テクノロジーの変化により本を出版し配布するコストは限りなくゼロに近づいてきています。本を製作するコストは同様にかかるでしょう。しかし、そこは問題ではありません。

　Amazon kindle, iPhone, iPad, Android, ... 電子書籍の台頭により徐々にデジタル化が進んでいます。iPad の魅力は、おそらく、持ち運べる書籍がコンセプトなのでは？とも感じています。スティーブ・ジョブズ氏が、「人は1日に10時間も本を読まない」とぶちきれたのはカラー本とバッテリーの関係を入念に検討し、やむを得ず10時間ぐらいの長さに収まったところを突かれたからだと感じています。ここのデザインのためにCPUスペックを落としたり、機能を削ったり、相当に煮詰めたことだと思います。

　その気になれば、個人で出版する事が容易な時代になっています。コストは、ほぼゼロ円です。AppStore ならぬ BookStore がデジタル化されるのも時間の問題でしょう。

　ここまでは、大半の方が想いを巡らせている事でしょう。実際のリアルな本を考えてみましょう。日本でも多少のサービスがあり、1冊から印刷できます。しかし、どこも中途半場で、発想が発注者への納品という形になっています。無駄が多すぎて笑えます。中には50冊以上から注文を受け付けますなんてところもあります。本を出版するのが夢というマニアやイベント用冊子以外に誰が買うんだよ？
私はコミケをやっていませんが、BBS時代に一度オフ会でコミケに参加した事があります。コミケでは、サークルのような形で同人誌を出版しており、グループ出版に近い形をとっています。最近の事情をとんと知らないので、間違っているかもしれませんが、ここでも製本会社から納品された本を販売しているか、自前で印刷したものを製本して販売しているという形で収まっているのではないかと推察しています。

　発想の柔軟な海外では、いや、日本ほど書籍好きではなく独特の市場を形成していない海外ではもう少しスマートです。
http://www.cafepress.com/cp/info/help/learn_book.aspx
他にもいくつかあったはずです（忘れてしまいました）。

　要するに、書籍のサイズや素材が画一化されていて、デジタル印刷になっているのであれば、出版したい人が書籍を印刷会社に登録し、ウェブ販売、または、書籍販売サービスAPIを介して個人が書籍を販売し、リアルタイムに注文を受けた印刷・製本会社が、本を注文した個人に書籍を印刷して郵送するって事です。凸版印刷さんあたり、サービスしてみませんか？いかがですか？
「ウェブを変える１０の破壊的トレンド」にもあったように、キーワード「ダイレクト」は、とても重要な要素です。Google や Amazon や iPhone や iPad をスキップして、リアルな書籍は個人が売る時代がやってくるのです。

　販売部数が足りなくて、休刊した有用な雑誌は、そのビジネス・モデルを変えて存続しています。
一例をあげるとDr.Dobb's Journalがそうです。
今までは、ビジネスとして成立するためには、これだけの部数が必要という形でした。これからは部数の制限が解除され、潜在的な市場が顕在化される事になるのです。個の時代は、多様化の時代でもあります。

　iPhone に見られるように、キーワード「ダイレクト」を知り尽くしている企業は「囲い込み戦略」をとるかもしれません。中間マージンを徹底的に排除し、競争力を上げ、市場を独占する。
そんな世界に、デジタル書籍を持ち込めば、リアル書籍の販売手数料まで搾取されるかもしれません。
そこで、デジタル書籍の中にリアル書籍の購入ページへのリンクを埋め込む必要があると思います。このリンクを拒否するデジタル Book Store があるならば、断固戦うべきです。
リンクを埋め込むにあたって重要になるのが、リンク・サービス。bit.ly の新たな形が、リンク変更に追随するサービスです。これ無くしてデジタル書籍とリアル書籍の繋ぎはできません。


　ダイレクトに販売されるようになった先の本屋は、どうなるのでしょうか？今や、町の本屋さんは役目を終え、静かに閉店しています。雑誌はコンビニで買えるし、専門雑誌は定期購読できるし、普通の本はネット通販で買えてしまいます。そこが離島であっても品揃えは同じです。
品揃えのない町の本屋さんに何を探しに行くというのでしょうか？その答えのひとつが、北海道では有名な「くすみ書房」にあります。
　大型書店の魅力は品揃えです。書店の店員さんがレイアウトしたものを我々顧客が視覚で捉えて本を選別していく･･･。あまりに細分化した書籍を揃えるのは厳しいものです。もしかしたら、将来大型書店は、アミューズメント型になっていくのでしょうか？。

あかん

PHP Extension の記事を書くとか予告しながら、ダメージが大きくて眠い・・・。また、Ubuntu 環境は、一度 dhcp 接続の設定になってから、固定IPの設定に戻したら、Postfix あたりの設定がぐちゃぐちゃになって、起動しなくなってしまった･･･。記事を書くにも手順が確認でけん･･･。

入院しました

　パラダイスです。前日は徹夜でした･･･。どっちみち、あのペースで仕事していたら入院してます。心臓がいくつあっても足りません。
という訳で、左鎖骨のプレート生活も明日までです。

もがー

　http://bugs.php.net/bug.php?id=40926
PHPのエクステンションで、どうも、libpq ,libpng をリンクさせると、SegFault でお亡くなりになる。逆に、リンクしないと、PHPがエクステンションをロードした時に、「エントリにない関数があるでー」と、ワーニングが出る。しかし、ワーニングが出るだけで、一応、他のエクステンションが libpq, libpng をロード済みであれば、よしなに計らってもらえているようだ…。
　前にも書いたように、openssl は、マルチスレッドや複数からの初期化に対応すべきである。クソっぽいと思っていたが、クソかもしんない。これが、セキュリィティの根幹を成すための共有ライブラリ？（お前が、かけーーーーーーって、ツッコミは勘弁）

追記： Ubuntu の環境でやると、SegFault しない…。libpq のバージョン問題か？これ？ dll hell ってやつか？ ldd でリンクしてるの同じって、確認したんだけどなぁ？？？
追記 2010/04/04: リンク・ミスでした。php pgsql は、libpq.so.4 に・・・作成したやつは、libpq.so.5 に・・・。rpmforge 使ってるから、postgresql本体は最新だけど、接続に使うlibpq は、古いバージョンのものを使っている状況って事でした。