68user's page 掲示板

Prev< No. 997〜1002> Next  [最新発言に戻る] [過去ログ一覧]
No. 997 # hum 2000/07/22 (土) 16:42:52
はじめまして。
勉強になるのでちょくちょく見させてもらっています。

crypt化した文字を復元することはできるのですか?

No. 998 # hum 2000/07/22 (土) 16:52:27
申し訳ないです。先ほどの追加です。

crypt化するのにperlでやっています。

#!/usr/bin/perl

$A ="AAAAAA"; #←crypt化する文字
$B ="BB"; #←KeyWord
print crypt ($A,$B);

No. 999 # 68user 2000/07/22 (土) 21:10:41
> crypt化した文字を復元することはできるのですか?
できないです。復元ができないようなアルゴリズムを採用している
からです。なので、辞書を使ったり、総当りで調べるしかありません。

ちなみに keyword じゃなくて salt と言います。

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あたりで
検討してみたいと思います。

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

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