From: forsyth@caldo.demon.co.uk forsyth@caldo.demon.co.uk
Subject: [9fans] create(2)/open(2) race for file creation
Date: Tue, 10 Feb 1998 08:59:14 +0000 [thread overview]
Message-ID: <19980210085914.g8qCDhAM_Z1j5U9xfmXHOIDBn9aEEJamMct3IKZHvwY@z> (raw)
i'm not sure i follow this.
in order to simplify one application that
purportedly has unusual needs, it is proposed as a sensible action,
and even dignified by reference to `research', to rush to change
a fundamental interface for dozens of other programs
(more if you include the ones gdb hasn't seen).
even then i wasn't sure i could understand the timing restrictions accurately
that prevented use of CHEXCL -- it seemed the race was
built into that application more than the kernel! but i hadn't
time to pursue it this week.
it's even more surprising, because (if one were to accept the
underlying assumptions, which as yet i don't), gdb himself proposed
an alternative solution by a flag to open (or something)
that didn't require as much messing about, isolated the change
and allowed me to ignore the whole matter for the moment!
i recall a caustic comment made by a friend of mine when
someone from the CSRG included things such as `increasing dev_t to 64 bits'
on a 1987 slide describing `research' they were undertaking with Unix.
i'd concluded from that talk that clever people can still be tempted just
to prat about with trivial things, and even then without THINKING.
if i were truly exercised by its existence, i might consider removing the
race in the implementation of the system call (in port/chan.c).
in practice, i'd probably think a little bit about the implications
of that, and then decide against bothering to do even that.
in a distributed system with processes
concurrently creating and destroying names, especially in the presence
of union mounts (where it isn't possible in general to rendezvous at a shared
file server because there isn't guaranteed to be a unique one),
some form of name-race is a fact of life,
and one might as well look to other mechanisms for a solution
to general synchronisation problems.
it's not even worth a reference to the Race Relations Board.
next reply other threads:[~1998-02-10 8:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-02-10 8:59 forsyth [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-02-26 23:30 Russ
1998-02-26 23:01 G.David
1998-02-26 22:16 G.David
1998-02-26 19:33 Eric
1998-02-26 0:24 G.David
1998-02-26 0:04 G.David
1998-02-25 23:42 G.David
1998-02-10 14:34 G.David
1998-02-09 21:21 G.David
1998-02-09 16:42 G.David
1998-02-09 8:05 Dan
1998-02-08 22:48 G.David
1998-02-08 22:18 Photon
1998-02-08 21:44 Rob
1998-02-08 21:10 G.David
1998-02-08 16:52 G.David
1998-02-08 16:16 G.David
1998-02-08 16:10 Dave
1998-02-08 15:48 G.David
1998-02-08 5:09 G.David
1998-02-08 2:01 Rob
1998-02-08 0:27 G.David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19980210085914.g8qCDhAM_Z1j5U9xfmXHOIDBn9aEEJamMct3IKZHvwY@z \
--to=forsyth@caldo.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).