From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <725518204b6f4564c0a2569e655ac310@felloff.net> From: Charles Forsyth Date: Wed, 30 Nov 2016 15:08:33 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11360774247d5805428614a7 Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af89caba-ead9-11e9-9d60-3106f5b1d025 --001a11360774247d5805428614a7 Content-Type: text/plain; charset=UTF-8 On 30 November 2016 at 15:02, Giacomo Tesio wrote: > > But reading that thread I can't actually see why the OEXCL path has been > taken instead of eliminating the race mapping the syscall to the 9p message. > I mean except backward compatibility. > I suppose you'll find out, but I'd expect that all but a handful of instances want the existing effect and are untroubled by any potential race. Given that OEXCL then seems to handle the handful, it seems a reasonable approach. The ocreate would just put the race in a different place, wouldn't it? --001a11360774247d5805428614a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 30 November 2016 at 15:02, Giacomo Tesio <giacomo@tesio.it> wrote:
But reading that thread I can't actua= lly see why the OEXCL path has been taken instead of eliminating the race m= apping the syscall to the 9p message.
I= mean except backward compatibility.

I suppose= you'll find out, but I'd expect that all but a handful of instance= s want the existing effect and are untroubled by any potential race.
<= div class=3D"gmail_extra">Given that OEXCL then seems to handle the handful= , it seems a reasonable approach.
The ocrea= te would just put the race in a different place, wouldn't it?
--001a11360774247d5805428614a7--