Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #61

Re: mkdir() and thread safety()

Show all headers | View raw

George Neuner <gneuner2@comcast.net> writes:
> On Thu, 31 Mar 2011 11:14:25 +0100, Rainer Weikusat

[...]

>>> There is no requirement for atomicity. You can't just make up requirements because
>>> they seem reasonable to you.
>>
>>And there is also no requirement that the implementation doesn't use
>>the 'file database created during booting' in the way I outlined
>>above EXCEPT that this would also be a broken implementation because
>>of the TOCTOU-race. Coming to think of it, it should also be okay to
>>let mkdir fail randomly with EEXIST since the result is again
>>identical: mkdir will or won't fail for some reason which has no
>>specific relation to the state of the filesystem at the time the
>>request was executed whatsoever.
>
> Local filesystems (typically) are designed to provide a serial
> consistent view ... but distributed filesystems make other choices.
>
> NFS was designed to have serial (transactional) consistency similar to
> a local filesystem.   But there are other distributed filesystems,
> e.g., AFS (CMU's Andrew file system), that provide much weaker
> consistency.

In the context of what is or isn't required for a standard-conforming
mkdir implementation this isn't really relevant. Also, this is another
'all kinds of weird stuff are known to exist' ("Since Kennedy was
shot. ...") statement. One could go so far as to call this
'FUD'. Either you have definite information that mkdir behaves in
such-and-such a (non-standard conforming) way on implementation X of
filesystem Z then please say so. Or you don't. Then, you are adding
nothing of any use to this particular thread.

[...]

> Good developers have to be defensive.

[...]

> you cannot rely on anything in the local API.

Taking this as it was stated, computers cannot be programmed at
all. While you are technically correct (eg, a power outage at the
wrong time or bits flipping themselves in a DRAM could produce almost
arbitrarily weird effects) this is not a practical standpoint insofar
'getting something done' is the objective: This implies that the
assumption that things will generally behave as they are supposed to
while deviations will be rare, identifiable and 'work-aroundable' has
to be made.

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: mkdir() and thread safety() David Schwartz <davids@webmaster.com> - 2011-03-30 14:53 -0700
  Re: mkdir() and thread safety() Richard Kettlewell <rjk@greenend.org.uk> - 2011-03-30 23:20 +0100
    Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-03-31 11:17 +0100
  Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-03-31 11:14 +0100
    Re: mkdir() and thread safety() George Neuner <gneuner2@comcast.net> - 2011-03-31 19:13 -0400
      Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-01 16:52 +0100
        Re: mkdir() and thread safety() George Neuner <gneuner2@comcast.net> - 2011-04-03 13:59 -0400
          Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-08 23:59 +0100
    Re: mkdir() and thread safety() David Schwartz <davids@webmaster.com> - 2011-04-01 12:22 -0700
      Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-01 21:03 +0100
        Re: mkdir() and thread safety() David Schwartz <davids@webmaster.com> - 2011-04-01 14:27 -0700
      Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-01 21:23 +0100
        Re: mkdir() and thread safety() David Schwartz <davids@webmaster.com> - 2011-04-01 14:28 -0700

csiph-web