ptraceシステムコール入門 ― プロセスの出力を覗き見してみよう！ - プログラムモグモグ
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
システムコールを減らすシステムコール
前回まで、mmap(2)によるコピー処理の高速化について紹介してきた。mmap(2)にはまた、システムコールが呼ばれる回数を削減し、処理速度を高速化するという効果もある。今回は、共有メモリの観点から、その機能を紹介する（編集部） システムコールを減らすシステムコール mmap(2) 前回まではコピープログラムを例に挙げながら、mmap(2)を使うことでコピー処理を高速化できることを紹介してきた。連載第1回目で説明したように、処理速度を高速化したければ、基本的にはシステムコールは少ない方がよい。システムコールを実行すれば、その分プログラムとカーネルの間でのデータのコピーや処理の切り替えが発生し、それだけ処理速度が遅くなる。 しかし、例外的に処理を高速化できるものもある。その代表格がmmap(2)だ。mmap(2)はシステムコールだが、このシステムコールを利用すると、最終的にはシステムコールが
fdatasync() と fsync() の違い - kameidの備忘録 - Sharpen the Saw!
fdatasync() と fsync() について全く知識が無いので、調べ中。 両方とも、データをハードディスクに *物理的に* 格納するためのファンクションのようだ。 fdatasync() は (システム・コールから戻る前に) ファイルの全てのデータ・バッファーを ディスクにフラッシュ (flush) する。これは fsync() に似ているが、アクセス時刻のようなメタデータを更新しない。 データベースにアクセスしたり、ログ・ファイルに書き込むような アプリケーションはしばしば小さなデータの断片 (例えばログ・ファイルの一行) を書き込み、それがハードディスクに物理的に格納されることを保証する ために、すぐに fsync() を呼び出す。不幸なことに、 fsync() は常に二回の書き込み操作を行なう: 一つは新しく書き込まれたデータを、 もう一つは inode の修正時刻を更新する
はじめてのひき - RecentFunctions
適当に羅列してみる。 システムコール epoll / kqueue 全くスケールしない select をなんとかするためのもの posix_spawn fork+exec は間違ってたんや… signalfd シグナルハンドラで pipe に write するとかしなくていい。 Linux だけ。 splice vmsplice fd を直結させる的なにか。 sendfile の拡張的な感じ、なのかな libc asprintf glibc とか Mac libc の文字列系関数は結構べんり。 backtrace / backtracee_symbols デバッグ用に便利。 Linux Mac ともにある。
POSIX close(2) is broken
In the world of POSIX, everything is a file. Well, sort of. There's sockets and pipes, which behave rather like files except that you can't seek on them and they have some extra metadata. And there's devices, where sometimes you can only read and write appropriately-sized blocks, not individual bytes. And then there's terminals, which are all sorts of weird. But in all these cases, you've got a fi
UNIX上でのC++ソフトウェア設計の定石 (3) - memologue
鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee
8月版 ブート時間の短縮にかけるカーネルアスリートたち（1/2） － ＠IT
小崎資広 2008/9/1 OLS（Ottawa Linux Symposium）が終わって気分も一新、Linuxカーネルメーリングリスト（LKML）でのパッチの投稿ペースがまた上がってきています。 先日、某所で議論したところ、2008年のOLSのハイライトは 基調講演でTOMOYO LinuxがTOMOYA Linuxと呼ばれていた Tシャツの平均サイズが10年間でMからXLに成長。みんな大きくなったね だとか。 それでは、2008年8月のLKMLでどんなことが起きたのか見てみましょう。 ブート高速化フレームワークの開発始まる OSのブート処理の1つに、デバイスを初期化する処理があります。これによりさまざまなデバイスが使用可能になり、ディスクやネットワークといったリソースが使えるようになるわけです。 従来、Linuxの起動処理において、デバイスドライバの初期化は1つ1つシーケンシャルに処
C言語: UNIX最速ファイルコピー
Created: Kazuki Ohta, 2006/06/14 Last Update: Kazuki Ohta, 2006/06/14 「write(2)の正しい使い方」と同じく、OS演習でやった事の延長線の記事を書いてみる。お題は「UNIX上で大規模ファイルを最速でコピーする方法」だ。一般的に、UNIXでファイルをcopyする際には以下のような方法が有る。 read -> write read -> write with posix_fadvice mmap -> mmap -> memcpy -> fsync mmap -> mmap -> memcpy -> fsync with madvise mmap -> write mmap -> write with madvise read, write, mmap辺りは良いとして、posix_fadviseというシステムコールが有
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
