Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
スレッド間通信のオーバーヘッドを比較する - Blog by Sadayuki Furuhashi
pthread_系の関数は mutex か cond しか待てないが、select/poll/epoll はファイルディスクリプタしか待てないので、両方待ちたいときに困る。 解決方法はいろいろあると思いますが、私の思いつく範囲では以下の４つ。 selectで待ち、シグナルで割り込む ファイルディスクリプタはselectで待つ。他のイベントはいったんキューに入れておき、シグナルを発生させてselectを中断させる。たしかlighttpdはこの方式だったはず。ただlighttpdはシングルスレッドなのでキューは使っていなかったような（うろ覚え） selectで待ち、パイプで割り込む selectで待つのだが、その中にpipe(2)で作ったパイプを１つ食わせておく。ファイルディスクリプタ以外のイベントはいったんキューに入れておき、パイプに1バイト書き込んでselectを中断させる。 select
富豪的バックアップのススメ - Blog by Sadayuki Furuhashi
間違ってrmしてしまったっ！！ ということは誰しも一度はあると思いますが、そう言うときのためにもバックアップやバージョン管理は重要なわけです。 しかしバックアップは１時間に１回や１日に１回程度しか行わないので、たとえば5分前に変更したプログラムをrmしてしまったら、その5分間の変更は水の泡です*1。何という損失！ 中でもやる気の損失が激しい。 上書き保存するたびにバックアップ そこで、これは受け売りなのですが、エディタでファイルを保存するときに常にバックアップを残すようにしています。 当然のことながら凄まじいファイル数になりますが、エディタで編集するのは大方プログラムや設定ファイルなので大した容量にはなりません。今私のバックアップディレクトリを見てみると 2008年4月2日16時15分30秒 から累積して約5万個のファイルが残っていますが、サイズは 400MB 程度です。 今時のHDDから
別のプロセスにファイルディスクリプタを転送する - Blog by Sadayuki Furuhashi
UNIXドメインソケット経由でファイルディスクリプタを別のプロセスに渡すことができるらしいと言うことで、試してみました。Manpage of UNIX Manpage of SEND 標準出力を別のプロセスに渡してみます。渡された側のプロセスは、自分の標準入力からの入力を、渡された標準出力に出力しています。 ライブラリ（fdtransport.h）： #ifndef FDTRANSPORT_H__ #define FDTRANSPORT_H__ #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/socket.h> #include <sys/un.h> #include <fcntl.h> #include <string.h> /* UNIXドメインソケットを待ち受ける */ /*
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
