68user's page 掲示板

Prev< No. 1000〜1014> Next  [最新発言に戻る] [過去ログ一覧]
No. 1000 # mm@biglobe 2000/07/23 (日) 23:37:53
unixはぜんぜん知らないのですが、
flockに関しては以前から疑問があったので、
ちょっとお伺いします。

>とか書いた時点で終わってます.2箇所直せば使えますけど
>普通そんなこと気付きません.
open の時点で $file が破壊されるってことですね。
これは、確かにしっかりしたドキュメントが必要だと思います。

>あと,デッドロックの発生を検知するのが難しいです.
flock でデッドロックが発生したら、意味ないのでは…?
flock がセマフォを使ってるのか、別の何かを使ってるかは知りませんが、
デッドロックを回避できるからこそ flock の価値があるんではないでしょうか?
それとも、セマフォとかの待ち行列の状態が検知できないという意味でしょうか?

>Perlで普通にflockを使っていると,たいがい
>まともにロックできないうえ処理速度が遅くなります.
こういう文章を読んで、flockはダメだと勝手に判断して、
もっと酷い、訳の分からない排他制御手段を考える人が出て来るような気が…

ただ、flockを使えばOSが対象ファイルごとに待ち行列を
用意することになるんでしょうから、チャット等が沢山使われるサーバーでは、
リソースを大量に消費して、レスポンスも悪くなるような気はします。
先のプロバイダの制限は、そういうことを嫌ったのではないでしょうか?

No. 1001 # Netboy 2000/07/24 (月) 04:32:13
>open の時点で $file が破壊されるってことですね。
はい,あと引数'2'だと,待っている間何も出来なくなるので
マズイ,ということで2箇所...としました.
シグナル起こしはあてにならないということで.

>デッドロックを回避できるからこそ flock の価値があるんではないでしょうか?
デッドロックは起きます.
flockには価値なんかありません.BSDでの互換性だけです.
言葉遊びでなく,確率というか危険度と考えてください.

flockして成功したプロセスが無限ループに入ったとき,
解除にはたいがいプロセス殺しが必要です.うまく殺せるか
どうかは不確実なので,この時点でデッドロックといえます.
symlinkやmkdirでの排他処理だとまだ通常のファイル操作で済みます.

>それとも、セマフォとかの待ち行列の状態が検知できないという意味でしょうか?
はい,検知と制御ができません.同じ意味でfcntlやセマフォも
使うのは難しいです.OSリソースを隠れて消費し,工夫しないと
システム全体の速度が低下します.

OSに付属する排他処理機構を,よく検証せずに使うのはまずいです.

私の経験だと,
- いつどのプロセスが何をロックして
- それを参照する何個のプロセスがどれくらいの時間待機しているか
外から判るようにしなければだめな感じです.

>訳の分からない排他制御手段を考える人が出て来るような気が
他人の手法を参考のうえ,排他処理の仕組みを自分で考えるのは
結構なことだと思います.

No. 1002 # mm@biglobe 2000/07/24 (月) 22:32:46
>解除にはたいがいプロセス殺しが必要です.うまく殺せるか
>どうかは不確実なので,この時点でデッドロックといえます.
なるほど、もし解除できないということが起こるなら、
確かにデッドロックですね。
unixを触ったことがないため、そのヘンは、何となくシステムを
信頼していました(^^;

>flockには価値なんかありません.BSDでの互換性だけです.
う〜ん、それが現状だとすると、問題ありそう…

>言葉遊びでなく,確率というか危険度と考えてください.
確かに、私の先の書き込みは、スパゲッティを食べる哲学者のレベルでの
話かも知れません(^^;

>OSに付属する排他処理機構を,よく検証せずに使うのはまずいです.
検証する能力がない人間が下手なことをするよりは、
システムが用意した機能をそのまま利用した方がマシ、
というスタンスでいたのですが、少なくともflockに関しては、
考え直さないといけないみたいですね。

>symlinkやmkdirでの排他処理だとまだ通常のファイル操作で済みます.
今後は、作成時からの経過時間検査による解除機能付きsymlink/mkdirあたりで
検討してみたいと思います。

>他人の手法を参考のうえ,排他処理の仕組みを自分で考えるのは
>結構なことだと思います.
これは、あくまでもっと低次元の話です。
「他人の手法」を正確に理解し、問題点を的確に把握した上で、
「自分で考える」のであれば、仰る通りすばらしいことだと思います。

No. 1003 # 68user 2000/07/25 (火) 00:31:46
Netboy さんは、ノンブロッキングの flock なら OK、
という立場ですよね?

で、いくつか疑問があります。

> flockには価値なんかありません.
fcntl には価値がある、という話でしょうか。それとも
両方価値がない、という話ですか?

> flockして成功したプロセスが無限ループに入ったとき,
という状況って、起こり得ますか? (現象事態は
root が SIGSTOP 送れば容易に発生しますが)

Netboy さんは、どういうプログラムを想定しておられます?
ちなみに僕が考えたのは、カウンタとか web BBS とかです。

> Perl で普通にflockを使っていると,たいがいまともに
> ロックできないうえ処理速度が遅くなります.
僕の環境では「まともにロックできない」というのは
経験したことはありません (1000回カウントアップしたつもりが、
カウンタデータファイルを見ると998回しか実行されていない
というのはあった。原因は不明)。

それと flock は、symlink・mkdir よりは速かったです。
しつこいですが、僕の環境では、です。

# あと、排他処理はいつも symlink でやるので、flock を
# 使いこんだことはないです。

> 訳の分からない排他制御手段を考える人
http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm (笑)

No. 1004 # mm@biglobe 2000/07/25 (火) 00:56:39
>http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm (笑)
あはは、どもです。どこだったか忘れてました。

No. 1005 # Netboy 2000/07/25 (火) 04:54:43
>Netboy さんは、ノンブロッキングの flock なら OK、
>という立場ですよね?
はい.
動作環境を知っていて,使えると判断した用途にはOKです.
例えば常駐動作のサーバー用のスクリプトなんかにはいいですよね.

>それとも 両方価値がない、という話ですか?
いいえ,fcntlは意味があると思います.
POSIX準拠(?)+NFS対応だそうですし.
あれはOSの内部操作をそのまま出してくれているんですよね?
でもWin環境で互換性が無いので,あまり使いません.

>> flockして成功したプロセスが無限ループに入ったとき,
>という状況って、起こり得ますか? (現象事態は
>root が SIGSTOP 送れば容易に発生しますが)
次のようなものです.

- スクリプトの単なるバグ
- 作成中のスクリプトのテスト時
- 予期しないデータを与えられたスクリプト
- Perlインタプリタがコケたとき.OSリソース逼迫下.
- インタプリタのバグ.
- Apacheの設定ミス,管理者の不注意な設定変更.
- クラッキングを受けたサーバー

>Netboy さんは、どういうプログラムを想定しておられます?
>ちなみに僕が考えたのは、カウンタとか web BBS とかです。
私も同じです.
スクリプトのバグでは,機種/環境依存文字の訂正で
ある予期しない文字列のとき置換操作が止まらなくなる...など.

>僕の環境では「まともにロックできない」というのは
>経験したことはありません
それは68userさんだから(笑).
普通の人は下で書いたスクリプトみたいな感じです.
NFSを使っているプロバイダの場合,もっと状況は複雑になります.

>それと flock は、symlink・mkdir よりは速かったです。
う〜ん,負荷が掛かった時なんです,問題は.
デッドロックの自動検出と,flockの解除のための
pidの保存操作や予防措置も含めてください.

MMX233+FreeBSDで1000個の掲示板が同時動作で平均待ちプロセスが2〜4個
の状況('97のテレホ時)でflockを使うかどうか,です.

>訳の分からない排他制御手段を考える人
いや,いいんじゃないですか.誰もが通る出発点だと思います.
68userさんだって,miniBBSのアレとか,ほら,悪い思い出(笑).
混雑時の実用性や設置性を検証すると,面白いことになります.

No. 1006 # ちゃいぱ [URL] 2000/07/25 (火) 15:19:18
はじめに、flockについて質問した者です。

CGIをダウンロードした人にプロバイダ来たメールで、
やはり、「NFSがらみで、flockが利用不可能な状態」とのことでした。
CGIの方は、WIN95も考慮して、ロックファイルの有無で対処いたしました。

話は、変りますが、DNSサーバーについて知識として教えて下さい。
rlogin,ftp,telnetなどで、ホスト名を指定した時に、どのようにして、
DNSサーバーとやり取りをしているのですか?
DNSサーバーはhttpみたいなデーモンが動いているですか?(私の買った本には、この辺書いていなかった)

ちょっと、気になったので、よろしくお願い致します。

No. 1007 # 68user 2000/07/25 (火) 16:27:35
flock の件は後程。

> rlogin,ftp,telnetなどで、ホスト名を指定した時に、どのようにして、
> DNSサーバーとやり取りをしているのですか?
rlogin/ftp/telnet などは、ユーザからホスト名を受け取ると
gethostbyname(3) などを使って、ホスト名から IP アドレスを
得ようとします。

gethostbyname の内部では、ソケットを使って DNS サーバに
アクセスします。で、DNS サーバは UDP の port 42 を
listen していて (UDP だから listen という表現は変?)、
クライアントからの問い合わせに応じて IP アドレスを
教えたり、他の DNS サーバに問い合わせたり、見付から
ないよと答えたりします。

こういう問い合わせを行う DNS クライアント (この例では
gethostbyname) のことを resolver と言います。resolver は
概念的なもので、問い合わせを一手に引き受ける resolver
サーバのようなものがあるわけではありません。ただのライブラリです。
なので、自分で外部の 42/udp にアクセスする DNS クライアントを
書く事もできます。

> DNSサーバーはhttpみたいなデーモンが動いているですか?
UNIX 界で DNS サーバとして有名なのは bind です。
プログラム名は named。
# apache と httpd の関係と似ています。

No. 1008 # 68user 2000/07/25 (火) 16:57:08
> こういう問い合わせを行う DNS クライアント (この例では
> gethostbyname) のことを resolver と言います。
いや、違うか。

res_query, res_search, res_mkquery, res_send, res_init,
dn_comp などの DNS サーバへ問い合わせを行うライブラリ
関数群のことを resolver といいます。gethostbyname などは
これらの関数を孫請けとして呼んでいます、かな。
# See resolver(3).

No. 1009 # ちゃいぱ [URL] 2000/07/25 (火) 17:01:14
回答ありがとうございます。

では、DNSクライアントとnamedデーモンが、
UDPプロトコルでportの42番でやり取りすると理解してよろしいですね。

すっきりしました。
ありがとうございました。

No. 1010 # gongo [E-mail] 2000/07/25 (火) 23:48:36
はじめまして、gongoと申します。
いきなりで申し訳ありませんが質問があります。
私はXアプリケーションの勉強を始めたばかりなのですが
XライブラリとXツールキットを用いたプログラムを書こうとして
行き詰まってしまいました。
と言いますのは、例えばXツールキットを用いて表示させた窓に
Xライブラリを用いて直線を引いたりする方法がわかりません。

XDrawLine(XtDisplay(w),XtWindow(w),gc,x1,y1,x2,y2);

といった感じでプログラムの中に書き込みますとコンパイルは
できるのですが、実行させるときにXDrawLineのところで
Segmentation faultで止まってしまいます。
本もいろいろと読みましたがどうにもうまくいきません。

作成途中のプログラムは以下のところにあります。
http://www.din.or.jp/~gongo/xtshirt.c(本体)
http://www.din.or.jp/~gongo/color.dat(色の数値)
どうか宜しくお願い致します。

No. 1011 # 68user 2000/07/26 (水) 00:48:58
> では、DNSクライアントとnamedデーモンが、
> UDPプロトコルでportの42番でやり取りすると理解してよろしいですね。
その通りです。

> 例えばXツールキットを用いて表示させた窓に
> Xライブラリを用いて直線を引いたりする方法がわかりません。
非常に興味のある分野なので答えたいのはやまやまなのですが、
Xt を触ったことがないのでわかりません。でも、DrawLineOnWidget 内で
drawgc を使ってますが、DrawLineOnWidget を呼び出す前に
drawgc に GC をセットし忘れているように見えます。

あと、戻り値を見ると XtWindow(w) で NULL が返ってるのが
問題…なのかなぁ。解決法がわかったら教えて下さい。

No. 1012 # gongo [E-mail] 2000/07/26 (水) 01:39:54
> 非常に興味のある分野なので答えたいのはやまやまなのですが、

素早いご返答ありがとうございます。

> drawgc を使ってますが、DrawLineOnWidget を呼び出す前に
> drawgc に GC をセットし忘れているように見えます。

本によると、ウィジェットをリアライズした後にGCを
設定するようなことがかいてありましたもので
XtRealizeWidget(toplevel);
よりも後にdrawgcをセットすることにしたのです。
もう少し調べてみます。

> あと、戻り値を見ると XtWindow(w) で NULL が返ってるのが

すみません、これはどういうことなのでしょうか。
NULLが返ってくるというのはどのように調べたらよろしいのでしょうか。
NULLが返ってるとなるとおそらくここが悪いのだと思います。
う〜ん、もう少し調べてみます。

No. 1013 # 68user 2000/07/26 (水) 09:20:32
> XtRealizeWidget(toplevel);
> よりも後にdrawgcをセットすることにしたのです。
うーん、XDrawLine を呼んだ時点で X サーバとの通信が
行われると思うんで、やっぱりセットしておかないと
いけないんじゃないかなぁ…。GC は
    typedef struct _XGC * GC;
なので、GC の中身がゴミ (初期化してないので) だと
まずいと思うのです。

> NULLが返ってくるというのはどのように調べたらよろしいのでしょうか。
printf("%d\n",XtWindow(w)) としました。他の部分で同じことを
すると何か値が入っているのですが、XDrawLine の前で表示させると
0 となってしまうので、XtWindow がこけてるのかと思いました。

まぁ、知識がないのに推測を重ねるのもアレなので、
会社にある本を読んで調べてみます。

No. 1014 # gongo [E-mail] 2000/07/26 (水) 19:38:45
> 他の部分で同じことをすると何か値が入っているのですが、
> XDrawLine の前で表示させると 0 となってしまうので、
> XtWindow がこけてるのかと思いました。

例えばDrawLineOnWidget(label)の書いてあった手前に

printf("XtDisplay(label) = %d\n",XtDisplay(label));
printf("XtWindow(label) = %d\n",XtWindow(label));

と書いたところ、XDrawLine の前で表示させるのと同様に
次のようになってしまいました。

XtDisplay(label) = 67584
XtWindow(label) = 0

やはり0というのはまずいのでしょうか。labelを使い回して
いくつかの窓を表示させようとしているのがまずいのか・・・。

あとdrawgcのセットをDrawLineOnWidget(w)の中で下記のように
行ってみたところ、

drawgc=XCreateGC(XtDisplay(w),XtWindow(w),0,NULL);
XSetForeground(XtDisplay(w),drawgc,pixel[1]);
XSetBackground(XtDisplay(w),drawgc,pixel[0]);

DrawLineOnWidget(label)は抜け出て、ok6までは到達したのですが

X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
    Major opcode of failed request: 55 (X_CreateGC)
    Resource id in failed request: 0x0
    Serial number of failed request: 35
    Current serial number in output stream: 48

となってしまいました。

お手数お掛け致しまして申し訳ございません。

Prev< No. 1000〜1014> Next  [最新発言に戻る] [過去ログ一覧]