[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: opening twice with O_RDWR

Subject: Re: opening twice with O_RDWR
Date: Sun, 31 Dec 2006 17:10:22 -0500
User-agent: Pan/ (As She Crawled Across the Table)

On Sun, 31 Dec 2006 13:10:26 -0800, Paul Pluzhnikov wrote:

> Mike - EMAIL IGNORED <> writes:
>> My purpose is not relevant,
> It is, if you want a useful answer.

Apparently not; I got several useful answers.

>> but I assure you that the requirement is correctly stated.
> Where did you state your requirements? I must have missed that.
> So far all I've seen is incoherent "when I do this, result is not
> what I expect".

Requirement:  To allow a file to be opened not more than once
at a time.  (Emphasis: by any means, within or across

>> I confirmed that I can open the file O_RDWR simultaneously from
>> two processes.
> Yes, that's correct on UNIX; but not on Win32.
> Note that (AFAICT) you never mentioned two processes before this
> point, so the answers you've got related to a *single* process.
>> Seems to me like a good way to make a mess of a file.
> If you want multiple processes to cooperate on writing a single file,
> the proper way to achive that is with "advisory file locking"; see
> "man flock".

Thanks for this; I will read it later, but a quick look suggests
that it is what I need.

>> I guess I will use a locking file opened from a singleton.
> This approach has the problem that if "lock holder" dies, then no
> other process can do anything until "manual" cleanup. Advisory
> file locking avoids that -- the locks are cleaned by kernel when
> the process dies.
> Also, whether the locking file is opened from singleton or not is
> irrelevant -- singleton doesn't help you in any way that I can see
> (given your statement of the problem so far), and singleton doesn't
> work across processes.

The singleton will open the file once but allow access from different
objects without potential interference, or risk of multiple open
attempts (thereby protecting me from my worst enemy -- myself).  While
the present process is not multi-threaded, if it were, access to the
singleton would be protected by a mutex.

> Finally, may I suggest some light reading for the New Year:
> Cheers,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]