"Jason Zions" <yyyyyyyy@xxxxxxxxxxxxxxxxxxx> wrote:
>
> >> Or, you could simply write your threaded applications to always pass
> >> fully rooted paths. Seems like a much simpler change to me.
> >
> >``You could simply write your apps so that ...'' is not always that
> >simple in the real world. Within the portions of the application that
> >you write yourself, you can stick to arbitrary conventions, but there
> >may be third-party components, some of which you don't have source code
> >to, others which would be hard to modify.
>
> Either they're thread-safe, or they're not. APIs which pass pathnames
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> can be threadsafe in the presence of chdir() calls only if they're fully
> rooted. If you don't know if your third-party components use chdir(),
> assume they do and protect yourself. If the component claims to be
> threadsafe, then it already uses rooted paths; if it doesn't do so, then
> the claim is patently false.
>
> This isn't an "arbitrary convention" I suggested. It's how to write code
> in the presence of other threads which could be doing *anything*.
That mistake is at the heart of the threads fiasco. It is not even
remotely true - thread safety is a horribly context dependent concept
and, without a clear specification of the CONCEPTS used by POSIX
threads, it isn't correct to say that something is or isn't thread
safe (in absolute terms).
Let's consider an internationalised open. Obviously, it must include
the locale. But that is thread-specific, so no problem. Well, not
really. What about a system that has locale-specifying attributes
associated with a directory (e.g. a '.locale' file or directory
attribute)? Obviously a useful extension. So how should symbolic
in that directory be interpreted? And (getting back to the example
given), how should relative path names be interpreted? Should they
be aware of the locale of the current working directory?
The problem about standardising mechanism and not concept is that such
questions arise, and are resolved by more-or-less arbitrary hacks to
eliminate (or specify) a particular ambiguity or inconsistency. But
there are an unbounded number waiting in the wings. You are saying
that POSIX should add the extra constraint that relative paths should
not be used in threaded applications; that is just one such hack and,
as with all hacks, it merely moves problems from place to place.
Starting from here, I don't have a solution, but no attempt to resolve
particular examples will do much good without tackling the problems in
the basic model. POSIX threads have already grown to a complexity that
blows the mind of most outsiders I describe them to - just HOW many
symbols do you need to define for threading support? If I bump into
Hoare, I may ask him what he thinks :-)
And, of course, POSIX threads are of little or no use for what I (and
many parallel programmers) want them for, as they carry far too much
baggage. This, in turn, provides an excuse for implementors not to
supply sufficiently tuned communication primitives, which means that
several classes of (good) HPC programming paradigms are practically
unusable. Which means that suitable interfaces don't get standardised.
And so on.
I know that people will accuse me of being negative, but all I am
saying is that we have reached an impasse, and that the solution is
NOT to build some extra construction to get a bit further.
On the other matter, does anyone have any interest in Really Lightweight
Threads? This is a very serious question for me.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: yyyy@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679
|