[#18186] [req] Marshal — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

14 messages 2002/09/05
[#18190] Re: [req] Marshal — matz@... (Yukihiro Matsumoto) 2002/09/05

まつもと ゆきひろです

[#18229] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

22 messages 2002/09/09
[#18230] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — nobu.nakada@... 2002/09/09

なかだです。

[#18231] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — "U.Nakamura" <usa@...> 2002/09/09

こんにちは、なかむら(う)です。

[#18232] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — nobu.nakada@... 2002/09/09

なかだです。

[#18233] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — "U.Nakamura" <usa@...> 2002/09/09

こんにちは、なかむら(う)です。

[#18234] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — WATANABE Hirofumi <eban@...> 2002/09/09

わたなべです。

[#18236] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — "U.Nakamura" <usa@...> 2002/09/09

こんにちは、なかむら(う)です。

[#18238] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — WATANABE Hirofumi <eban@...> 2002/09/09

わたなべです。

[#18241] Re: [ruby-cvs] rough/ext/stringio: * ruby-stringio.spec: 0.0.7, added changelog. — "U.Nakamura" <usa@...> 2002/09/09

こんにちは、なかむら(う)です。

[#18285] rubicon on EWS4800 — Koji Arai <JCA02266@...>

新井です。

59 messages 2002/09/13
[#18322] Re: rubicon on EWS4800 — Koji Arai <JCA02266@...> 2002/09/21

新井です。

[#18333] Re: rubicon on EWS4800 — kjana@...4lab.to (YANAGAWA Kazuhisa) 2002/09/21

In message <20020921.152641.11483667.JCA02266@nifty.ne.jp>

[#18336] Re: rubicon on EWS4800 — nobu.nakada@... 2002/09/21

なかだです。

[#18337] Re: rubicon on EWS4800 — Tanaka Akira <akr@...17n.org> 2002/09/21

In article <200209211605.g8LG52p04564@sharui.nakada.kanuma.tochigi.jp>,

[#18338] Re: rubicon on EWS4800 — nobu.nakada@... 2002/09/21

なかだです。

[#18341] Re: rubicon on EWS4800 — Tanaka Akira <akr@...17n.org> 2002/09/21

In article <200209211628.g8LGSxp04786@sharui.nakada.kanuma.tochigi.jp>,

[#18342] Re: rubicon on EWS4800 — nobu.nakada@... 2002/09/21

なかだです。

[#18343] Re: rubicon on EWS4800 — Tanaka Akira <akr@...17n.org> 2002/09/21

In article <200209211739.g8LHdKp05495@sharui.nakada.kanuma.tochigi.jp>,

[#18345] Re: rubicon on EWS4800 — nobu.nakada@... 2002/09/22

なかだです。

[#18349] Re: rubicon on EWS4800 — Tanaka Akira <akr@...17n.org> 2002/09/22

In article <200209220415.g8M4Fkp24392@sharui.nakada.kanuma.tochigi.jp>,

[#18374] Re: [ruby-cvs] ruby/ext/tcltklib: * eval.c (ruby_run): should set toplevel visibility again here. — WATANABE Hirofumi <eban@...>

わたなべです。

20 messages 2002/09/25
[#18376] Re: [ruby-cvs] ruby/ext/tcltklib: * eval.c (ruby_run): should set toplevel visibility again here. — matz@... (Yukihiro Matsumoto) 2002/09/25

まつもと ゆきひろです

[#18377] Re: [ruby-cvs] ruby/ext/tcltklib: * eval.c (ruby_run): should set toplevel visibility again here. — nobu.nakada@... 2002/09/25

なかだです。

[#18378] Re: [ruby-cvs] ruby/ext/tcltklib: * eval.c (ruby_run): should set toplevel visibility again here. — WATANABE Hirofumi <eban@...> 2002/09/25

わたなべです。

[ruby-dev:18405] Re: pstore.rb can make a broken store

From: Tanaka Akira <akr@...17n.org>
Date: 2002-09-27 17:55:59 UTC
List: ruby-dev #18405
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, 桂遊生丸)

In This Thread

Prev Next