ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き - - emacsでリアルタイムに構文チェックを行う方法(flymake)
emacs でリアルタイムに構文チェックする方法です．flymakeを使います．仕組みとしては コーディング中に C-x C-s を押すと，バックグラウンドで make が走る make がエラーを出した場合は，該当するコードをハイライト表示する だけです．恐ろしく便利です． 参考 開発元 http://flymake.sourceforge.net/ すでに他の方のブログでも取り上げられています． flymake でリアルタイム文法チェック - とりあえず暇だったし何となくはじめたブログ Flymake を使って編集中にシンタックスエラーを検出する — ありえるえりあ インストール emacs22以降であればflymakeはデフォルトでインストール済です． 設定 flymakeは，構文チェックの処理を外部プログラムに丸投げしています．たとえば構文チェッカとして make を使う場合は，以
革命の日々！ hidden symbol が PLT経由してるってホンマかいな？
とBinary Hacks#29を見ながら、高林さんをdisって見るテスト :-) とゆーわけでテスト 以下のファイルを準備 foo.c extern void bar(void); void foo(void){ printf("foo\n"); bar(); } bar.c void bar(void){ printf("bar\n"); } libfoo.map { global: foo; local: *; }; あ、このバージョンスクリプトはfoo関数以外はライブラリ外から 呼べなくするよん。って意味ね ＞ Binary Hack読んでない人へ んで以下のようにコンパイル gcc -shared foo.c bar.c -o libfoo.so -Wl,--version-script,libfoo.map んで objdump -d して、foo関数を見ると以下 000000
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
UNIX上でのC++ソフトウェア設計の定石 (4) - memologue
鉄則4: スレッドの「非同期キャンセル」を行わない設計にしよう スレッドの非同期キャンセルとは： あるスレッドが別のスレッドを即座に強制終了すること 単に「設計が楽だから」「シンプルになるから」という理由でスレッドの非同期キャンセルを使うのはやめよう 一見楽そうに、シンプルそうに見えるだけ。様々な問題を引き起こす可能性が。問題の詳細を把握しないまま、スレッドの非同期キャンセルを行う設計にしないこと！ pthread規格では、あるスレッドの処理を別のスレッドが強制的に中断することが許可されています。これを、スレッドのキャンセルと呼びます。 スレッドのキャンセルには次の二種類があります。 方式１： 非同期キャンセル(PTHREAD_CANCEL_ASYNCHRONOUS) キャンセルは即座に行われる 方式２： 遅延キャンセル(PTHREAD_CANCEL_DEFERRED) キャンセルは、スレ
UNIX上でのC++ソフトウェア設計の定石 (1) - memologue
UNIXは、Windowsなどの“開発者に優しい”OSと比較すると、シグナルやスレッドの利用に関して制限事項が多いですが、それを知らずにアーキテクチャ設計および実装を行ってしまうケースが散見されます。これは、再現困難なバグの温床となるでしょう。 そこで、罠に嵌らないための「鉄則」を何回かに分けて書いてみようと思います。 鉄則1: シグナルの送受に依存しない設計にしよう 他プロセスおよび自プロセスに対し、非同期シグナルを配送して処理の流れを変える設計はやめよう 非同期シグナルとは、SIGUSR1・SIGUSR2・SIGINT・SIGTERM などの、killシステムコールによって生成・配送されるシグナルのこと 単に無視(SIG_IGN)するのは問題なし スレッドとシグナルの併用もやめよう 動作の予測が困難、デバッグが困難 説明： 同期シグナルとは、SIGSEGV,SIGBUS,SIGPIPE
localtimeやstrtokは本当にスレッドセーフにできないのか (1) - memologue
googleから私の日記に、localtime_r や strtok_r, getpwnam_r などのキーワードで飛んでくる方が結構多いので、ちょっと関連する話題を書いてみます(内容の割に長い…)。 さて、8/9の日記で、POSIXのlocaltimeという関数(下記)を取り上げ、 struct tm *localtime(const time_t *timer); この関数を複数のスレッドが同時に使うと処理が破綻すると書きました。また、この関数はシグネチャが腐っているので、libcの外側でmutexを使っても処理の破綻を回避することはできず、localtime_rという代用関数を使うしかないとも書きました。POSIXで示されている代用関数(TSF)の一覧は、8/21の日記に書いた通りです。 本日は視点をちょっと変えてみて、「localtimeのシグネチャは本当にダメダメなのか？」に焦点
非同期シグナルとanti-pattern - memologue
sigsafeというUNIX向けの小さなライブラリがあります。これは、「シグナルを正確に取り扱うのは非常に難しい、俺たちのライブラリを使うと随分楽になるよ」といった趣旨の、アセンブラとCで書かれたライブラリで、それなりの種類のOS、CPUがサポートされています。 このライブラリ自体の使い方、使い勝手、あるいはどう実装されているかについてはまだ把握しきれていないのですが、ドキュメントに有用な部分があるのでご紹介します。 http://www.slamb.org/projects/sigsafe/api/patternref.html です。非同期シグナルを使用したコーディングを行う際の、一種のアンチパターン集になっています。 悪い例1: signal safe ではない関数をシグナルハンドラから呼んでしまう void unsafe_sighandler_a(int signum) { pri
memologue - UNIX上でのC++ソフトウェア設計の定石 (2)
鉄則2: シグナルハンドラで行ってよい処理を知ろう sigaction関数で登録したシグナルハンドラで行ってよい処理は非常に限定されている 次の３つの処理だけが許されている 自動変数の操作 “volatile sig_atomic_t” 型の大域変数の操作 「非同期シグナルセーフ」関数の呼び出し これ以外の処理を記述しないこと！ 説明： シグナル受信時に何らかの処理を行うためには、シグナルハンドラと呼ばれる関数を用意し、それをsigaction関数でシグナル名と紐付けておけばOKです。しかし、シグナルハンドラ内で行ってよい処理は、上記の通り非常に限定されています。これを把握しないまま奔放なコードを書くと次のような現象が起き得ます： 問題1: プログラムがデッドロックする危険がある タイミングに依存する、再現困難なバグの原因となる デッドロックの発生が典型例だが、それ以外にも関数の戻り値不正
シグナルハンドラからのforkするのは安全か？ (1) マルチスレッドの場合 - memologue
マルチスレッドのプログラムが、(シグナルハンドラ以外から)forkするときに注意事項があることは既に書きましたが、「forkをシグナルハンドラの中から行いたい」というケースでは、さらに追加の注意事項があります。 一般に、シグナルハンドラでforkしてよいのは次の2つのどちらかの場合だけです。どちらも満たさないケース、例えば「フォークハンドラ*1関数内でprintfを呼んでいる」ケースではシグナルハンドラでのforkは安全ではありません。 pthread_atforkでフォークハンドラが登録されていない pthread_atforkでフォークハンドラが登録されており、その関数が非同期シグナルセーフ(async-signal-safe)である。つまり、規格で非同期シグナルセーフとされている数の関数しか呼んでいない関数である。 pthread_atforkとはPOSIXで定められている関数で、マ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://feed.designlinkdatabase.net/feed/outsite_299958.aspx