Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.apps > #71
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.os.linux.development.apps |
| Subject | Re: mkdir() and thread safety() |
| Date | 2011-04-08 23:59 +0100 |
| Message-ID | <878vvk1h9u.fsf@sapphire.mobileactivedefense.com> (permalink) |
| References | (3 earlier) <d18b0392-2e9d-49e5-911b-0b0a07c3f082@i35g2000prd.googlegroups.com> <87tyejtx4u.fsf@sapphire.mobileactivedefense.com> <sma9p6t5m5q3cg20ft3ml0gc5f77oonr39@4ax.com> <87k4fe9df1.fsf@sapphire.mobileactivedefense.com> <oibhp65b6a5nuuije3niiif8qgef1rss93@4ax.com> |
George Neuner <gneuner2@comcast.net> writes:
> On Fri, 01 Apr 2011 16:52:50 +0100, Rainer Weikusat
>>George Neuner <gneuner2@comcast.net> writes:
>>> 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.
>
> FUD is a strong word to apply to sound advice. Linux now supports
> more than forty different filesystems and believing that you can
> successfully work with all of them based only on understanding the
> filesystem API is wrong.
In the context of what is or isn't required for a standard-conforming
mkdir implementation, this is still irrelevant. Also, this is still a
general statement lacking any real information and consequently, it is
basically just fearmongering: You claim to know something about some
of these 'forty different filesystems' which will cause unnamed
problems when not specifically mentioned operations are carried out in
an unknown environment, the short version of that is 'shit can and
does happen' and in absence of more specific information about this,
the only sensible reaction is 'ignore the possibility until shit does
happen and then, deal with the specific problem as required'.
It is neither possible to write code which can deal with unknown
problems nor to write code which can deal with all conceivable
problems and if it was, it wouldn't be desirable to do so because this
would mean adding a lot of code most of which won't be of any use
except obfuscating the source (a reader who is unfamiliar with the
contents of some text has to start with the assumption that everything
is relevant until the opposite has been proven).
>>> 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.
>
> Replying nonsense to statements taken out of context is not helpful.
> My full statement, which I stand by, was: "Excepting where the
> distributed file system makes the same guarantees you cannot rely on
> anything in the local API."
"It is only insofar possible to program computers as filesystem
operations can be avoided completely" isn't significantly less general
than 'it is impossible to program computers'.
Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar
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