様々なUNIX環境のecho.cの比較
UNIX V5, OpenBSD, Plan 9, FreeBSD, and GNU coreutils implementations of echo.c UNIX Fifth Editionのecho.cは、以下のような実装になっている。 main(argc, argv) int argc; char *argv[]; { int i; argc--; for(i=1; i<=argc; i++) printf("%s%c", argv[i], i==argc? '\n': ' '); } いかにも昔のC言語らしいコードだ。ヘッダーの#includeはなく、関数の戻り値の型も指定されない。仮引数の型も、今となっては物珍しいだろうが後書きだ。 OpenBSDのコードは以下の通り。 /* $OpenBSD: echo.c,v 1.7 2009/10/27 23:59:21 deraadt
Working with UNIX Processes を読んだ - @kyanny's blog
Working With Unix Processes という本を読んだ。 Thin の作者からの「時期バージョンを作るとき参考にする」というメッセージ*1が添えられていたのに惹かれて買った。著者のサイトで直販しているが、 Kindle Store からも購入できる。 この本は一言でいうと、 UNIX 系 OS のプロセスについての本だ。プロセスとは何か、という導入部から始まって、プロセス ID やプロセス名、終了コードへと言及し、 fork(2) やソンビプロセス、シグナル、そしてデーモンプロセスの説明あたりまで本編中で説明している。 UNIX プログラミングに関する類書は 1000 ページを超えるものが多いなかで、この本はわずか 100 ページほどしかなく容易く読める*2。しかしページ数が少ないぶん、あまり踏み込んだ内容とは言えず、全体的にやや浅い印象を受けた。すでに UNIX, Li
初めてのOS source code reading(UNIX 6th source code readingのススメ) - やる気のないブログ(A boring diary)
このエントリはhttp://d.hatena.ne.jp/takahirox/20120131/1328006885を和訳したものです。 はじめに 最近UNIX 6thのソースコードの読書メモを書き終えました。 みさなんにもUNIX 6thのソースコードを読むことをオススメします。 その理由をこのエントリで書いていきます。 まとめ UNIX 6thは初めてOSのソースコードを読む人にうってつけ！ 今すぐ読み始めましょう！ UNIX 6thのソースコードはこちらなどで読むことができます。 http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6 UNIX 6thのソースコードを読むことをオススメする理由 たったの10,000行 最近のLinuxカーネルのソースコードは100万行を超えています。全てを理解するのは至難の業です。 一方、UNIX 6thのカー
ファイルディスクリプタ（file descriptor）について調べてみた - kotaroito's notes
Perl Hackers Hub 第6回 UNIXプログラミングの勘所（2）を読んでいたがよくわからなかったので、Operating System ConceptsやMANなどを読んで一から理解してみる。 Operating System Concepts 作者: Abraham Silberschatz出版社/メーカー: John Wiley & Sons Ltd発売日: 2009/02/13メディア: ペーパーバック購入: 1人 クリック: 39回この商品を含むブログ (4件) を見る open()システムコール The open() system call first searches the system-wide open-file table to see if the file is already in use by another process. If it is, a
非同期双方向TCPコネクションプールの実装メモ - Blog by Sadayuki Furuhashi
TCPで、１回接続したコネクションをとっておいて、後で使い回したい。つまりコネクションプールを作りたい。これをどうやるか。4/29のエントリの続きです。 V-FIELDでは、データを待ち受けるときはselect()を使って、溜めてあるソケットに変化があったら、スレッドプールからスレッドを取り出して処理を行う、ということを行っていました。データを送りたいときは普通に溜めてあるソケットを使ってデータを送るのですが、両側から同時にデータが送信される可能性があるので、一度小さなデータをやりとりしてネゴシエーションしてから、実際のデータを送ります。コネクションプールの実装方法としては標準的な方法かな、と思っています。 それが、どうもselect()にはいろいろと問題があるらしいので、今度は違う実装にしたいと思っています。そこで、aio_read()。普通はselect()の次はepollかkqueu
AsyncIOについて(その2) - 最速配信研究会(@yamaz)
AsyncIOについて(その1)の続き. NONBlockでIO処理をする方法としてselectとシグナルを使う方法があるというのが前回の話だったが, selectはselectよりkqueue,epollで述べたとおり, ビジーループがかかるためあまり効率はよくなく,シグナル方式は制約があるためあまり使い勝手がよくない. というわけで新しく出てきたのがPOSIX Asynchronous I/O(AIO)という機構だ. これはIOのwaitをイベントドリブン形式にしてビジーループをなくそうというものだ. プログラムの流れとしては下記のようになる. 1. 対象となるファイルディスクリプタにシグナルハンドラもしくはイベントハンドラを登録しておく 2. aio_read/aio_writeを呼び出すと制御はすぐにユーザに戻る. 3．対象のファイルディスクリプタの処理が終わると登録されていたハン
第6回 UNIXプログラミングの勘所（3） | gihyo.jp
ネットワークプログラムとSIGPIPE 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。これは多くの場合、SIGPIPEの処理を忘れていることが原因です。SIGPIPEとは、切断されたネットワークソケットなどにデータを書き込もうとした際に送出されるUNIXシグナルです。特に設定しない限り、プロセスはSIGPIPEを受け取ると強制終了されます。そのため、通信が突然切断される可能性のあるTCPサーバにおいては、SIGPIPEを無視するよう設定する必要があります。 # デフォルトの動作（SIGPIPEの場合はプロセスの終了）に設定 $SIG{PIPE} = 'DEFAULT'; # SIGPIPEを無視するよう設定 $SIG{PIPE} = 'IGNORE'; # SIGPIPEを受信した際に実行するサブルーチンリファレンスを # 設定 $SIG{PI
第6回 UNIXプログラミングの勘所（2） | gihyo.jp
forkとファイルハンドル UNIX系のOSでは、複数のプログラムが、それぞれプロセスという単位で動作しています。forkというシステムコール[1]が呼び出されると呼び出したプロセスの複製がOSによって作成され、複製されたプロセス（子プロセス）がexecveというシステムコールを使って別のプログラムにすり替わる、というしくみでさまざまな処理を実行するようになっています。 「複製」と言っても、全部の情報が複製されるわけではありません。プロセスのメモリイメージが複製される[2]一方で、プロセスが開いている「オープンファイル記述」（open file description）（注3）は複製されません。forkのあとは、親プロセスと子プロセスの両者が、単一のオープンファイル記述を指す「ファイル記述子」（file descriptor）（注4）を持つことになります（図2）。 図2 for
ファイルディスクリプタについて（1） ～ファイルディスクリプタの概要
ファイルディスクリプタは、プログラムの外部との入出力を行う抽象的なインタフェースです。Unix/Linuxのファイルディスクリプタは、一般的なファイルだけでなくデバイスやソケットやパイプも対象としています。当連載は、ファイルディスクリプタの機能や管理方法などを提示します。第1回では、ファイルディスクリプタの概要を紹介します。 はじめに ファイルディスクリプタ（Windowsではファイルハンドル）は、プロセスや実行ファイルにとって外部の資源にアクセスしたりアクセスされたりする際に使用される抽象的なインターフェースです。 今日のプログラムは必ずと言っていいほど外部とのインターフェースを持っていますが、新しいディスクリプタや効率的な使い方がそれほど明確ではなかったりします。 当連載では、ファイルディスクリプタに関する調査・試行錯誤した結果、新しいディスクリプタを使用した感想や効率的な管理方法など
ウノウラボ Unoh Labs: Emacsでソースコード解析
週末に眼鏡と財布が壊れて踏んだり蹴ったりなbokkoです。 最近、週末に他の人が書いたソースコードを解析したりして遊んでいるのですが、 今回はその際によく使っているツールについて紹介したいと思います。 moccur-edit.el これはソースコードを全体を検索する際によく使っています。 findとgrepをパイプでつなぐだけでも十分な気がしますが、 moccur-grep-findとmoccur-grep-gotoを組み合わせて使うと、 すぐさま該当箇所にジャンプできたりするので、楽々検索できます。 また、moccur-edit.elにはほかにも複数のファイルに散らばっているキーワードを 1つのバッファ上で編集できるなど非常に強力な機能が備わっているので、 Emacsを使うなら必ず入れておくのがオススメです。(tramp経由でmoccur-grep-findを実行するとすご
Geekなぺーじ：UNIX哲学の基本原則
「Basics of the Unix Philosophy」でUNIX哲学の基本原則がまとめられています。 UNIXの設計思想として紹介されていますが、多くは普通のソフトウェアを設計する場合にもあてはまると思われます。 1. Rule of Modularity(モジュール性): きれいなインターフェースで接続された、簡潔な部品を書きましょう。 2. Rule of Clarity(明瞭さ): 明瞭さは賢さよりも良いです。 3. Rule of Composition(構成): 他のプログラムと接続できるようにプログラムを設計しましょう。 4. Rule of Separation(分離): ポリシーとメカニズムを分離しましょう。エンジンとインターフェースを分離しましょう。 5. Rule of Simplicity(単純性): 単純化された設計をしましょう。複雑さは必要な時だけ追加しま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
