[#18151] Regexp.last_match — WATANABE Tetsuya <llama@...01.gate01.com>
渡辺哲也です。
[#18186] [req] Marshal — keiju@... (Keiju ISHITSUKA)
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
新井です。
まつもと ゆきひろです
In article <1031498274.659939.18144.nullmailer@picachu.netlab.jp>,
まつもと ゆきひろです
In article <1032189662.175916.22019.nullmailer@picachu.netlab.jp>,
[#18208] Re: [ruby-list:35875] Unsecure world writeabledir の警告 — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
わたなべです。
[#18229] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
わたなべです。
わたなべです。
こんにちは、なかむら(う)です。
わたなべです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
こんにちは、なかむら(う)です。
わたなべです。
[#18246] Re: missing/vsnprintf.c: printf("%+f", -0.0) — WATANABE Hirofumi <eban@...>
わたなべです。
At Tue, 10 Sep 2002 12:21:10 +0900,
[#18262] mswin32: EINVAL on Process.kill — Minero Aoki <aamine@...>
あおきです。
[#18274] $0 handling on DOSISH — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
なかだです。
岩月と申します。
なかだです。
こんにちは、なかむら(う)です。
なかだです。
こんにちは、なかむら(う)です。
[#18285] rubicon on EWS4800 — Koji Arai <JCA02266@...>
新井です。
新井です。
まつもと ゆきひろです
新井です。
まつもと ゆきひろです
新井です。
なかだです。
In message <20020921.152641.11483667.JCA02266@nifty.ne.jp>
なかだです。
In article <200209211605.g8LG52p04564@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200209211628.g8LGSxp04786@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200209211739.g8LHdKp05495@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200209220415.g8M4Fkp24392@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <200209260105.g8Q15PR08171@sharui.nakada.kanuma.tochigi.jp>,
なかだです。
In article <20020921.152641.11483667.JCA02266@nifty.ne.jp>,
なかだです。
In article <200209251737.g8PHbdR03024@sharui.nakada.kanuma.tochigi.jp>,
渡辺哲也です。
なかだです。
渡辺哲也です。
渡辺哲也です。
なかだです。
渡辺哲也です。
なかだです。
In article <200210020254.g922srH01700@sharui.nakada.kanuma.tochigi.jp>,
[#18314] class nest in module_eval — Minero Aoki <aamine@...>
あおきです。
[#18361] compile parse.y with -Wall — nobu.nakada@...
なかだです。
なかだです。
[#18371] Re: [ruby-cvs] ruby/lib/uri: * eval.c (ruby_run): should set toplevel visibility again here. — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#18374] Re: [ruby-cvs] ruby/ext/tcltklib: * eval.c (ruby_run): should set toplevel visibility again here. — WATANABE Hirofumi <eban@...>
わたなべです。
まつもと ゆきひろです
なかだです。
わたなべです。
いがらしです。少し前の話ですが。
わたなべです。
なかだです。
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
[#18391] pstore.rb can make a broken store — YANAGAWA Kazuhisa <kjana@...4lab.to>
# お願いされたから書いてみよう :-)
In article <20020926134339.C8DAE1EE12@milestones.dm4lab.to>,
[ruby-dev:18405] Re: pstore.rb can make a broken store
In article <200209271620.g8RGKtG02161@edge.back-street.net>, Takahiro Kambe <taca@back-street.net> writes: > 古くはINNか何かのメーリングリストだったと思いましたが、NetBSD(に限らな > いと思いますが)のfcntl(2)にありました。 > > This interface follows the completely stupid semantics of AT&T System V > UNIX and IEEE Std 1003.1-1988 (``POSIX'') that require that all locks as- > sociated with a file for a given process are removed when any file de- > scriptor for that file is closed by that process. This semantic means > that applications must be aware of any files that a subroutine library > may access. For example if an application for updating the password file > ... > database. Another minor semantic problem with this interface is that > locks are not inherited by a child process created using the fork(2) > function. The flock(2) interface has much more rational last close se- > mantics and allows locks to be inherited by child processes. Calling > flock(2) is recommended for applications that want to ensure the integri- > ty of their locks when using library routines or wish to pass locks to > their children. Note that flock(2) and fcntl(2) locks may be safely used > concurrently. おぉ。fcntl を発行した以外の file descriptor でも同じファイルにつながっ てるのを close すると unlock されるというのは確かに奇妙ですね。これが 変だというのは納得できます。 > flock(2)の方には、 > > NOTES > Locks are on files, not file descriptors. That is, file descriptors du- > plicated through dup(2) or fork(2) do not result in multiple instances of > a lock, but rather multiple references to a single lock. If a process > holding a lock on a file forks and the child explicitly unlocks the file, > the parent will lose its lock. > > といった記述もあります。ファイルをunlink(2)する場合は、最後にオープン > されていたファイル記述子がcloseされた時点で実体が消えることと対比する > と、極めて不自然に思えます。 > > > 思うに、lock は fork しても受け継げないので、3つのテーブルのうち file > flock(2)は受け継げます。 私は file descriptor につく(close-on-exec のような)性質だと思い込んで いたので fork では受け継げないと思っていたのですが、受け継げるんです ねぇ。まさに上記の NOTE の冒頭で述べられてる話で、読み方が足りなかった です。 -- [田中 哲][たなか あきら][Tanaka Akira] 「ふえろ! わかめちゃん作戦です$(C⊇」(Little Worker, 桂遊生丸)