タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

kqueueに関するsyossanのブックマーク (4)

  • Vim system calls when saving a file

  • Golang Kqueue Snippet

  • ASCII.jp:ファイルシステムと、その上のGo言語の関数たち(3)|Goならわかるシステムプログラミング

    Go言語でシステムプログラミングの世界を覗くこの連載では、前々回からファイルシステムに関係する話題を扱ってきました。 今回の記事では、その総まとめとして、アプリケーションから見たファイルシステム周りの最深部を辿っていきます。 扱う話題は次の4つです。 ファイルロック ファイルのメモリへのマッピング 同期・非同期とブロッキング・ノンブロッキング select属のシステムコールによるI/O多重化 ファイルのロック(syscall.Flock()) ファイルのロックは、複数のプロセス間で同じリソースを同時に変更しないようにするために「いま使用していますよ」と他のプロセスに伝える手法のひとつです。 ファイルロックの最も単純な方法は、リソースが使用中であることをファイル(ロックファイル)によって示すというものでしょう。 たとえば、古いプログラマ(30代以上?)にはお馴染みのCGI(かつて動的なウェブ

    ASCII.jp:ファイルシステムと、その上のGo言語の関数たち(3)|Goならわかるシステムプログラミング
  • *BSD で kqueue・kevent を使ってみよう

    *BSD で kqueue・kevent を使ってみよう select() の欠点 select() は複数のディスクリプタをポーリングできる便利なシステムコールです。 しかしパフォーマンスはよくありません。理由は以下の通りです。 ユーザプロセスは、監視対象のディスクリプタ一覧をユーザ領域からカーネル領域にコピーする必要がある。 カーネルがポーリング結果をユーザ領域に返す際もコピーしなければならない。 カーネルは、ポーリング対象のディスクリプタを知るために、配列の全要素を調べなければならない。 ユーザプロセスも、入出力可能なディスクリプタを知るために、配列の全要素を調べなければならない。 上記の作業は、select() を発行するたびに毎回行わなければならない。 select() のパフォーマンスが悪いことは広く知られていたので、 各 OS でいろいろな取り組みが行われてきました。 Sol

  • 1