From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <725518204b6f4564c0a2569e655ac310@felloff.net> From: Giacomo Tesio Date: Wed, 30 Nov 2016 16:28:06 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113ac0cc0dcd150542865a01 Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af8e1e12-ead9-11e9-9d60-3106f5b1d025 --001a113ac0cc0dcd150542865a01 Content-Type: text/plain; charset=UTF-8 2016-11-30 16:08 GMT+01:00 Charles Forsyth : > > 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? > Well not exactly: I will use the new create syscall (without OEXCL support) when I need such level of control and use ocreate with OEXCL when I do not care about the race and want a "create or truncate" default behaviour. But actually, I cannot see a use case where the create(2) default behaviour can be *wanted*. I just see many use case where it can be tollerated: the create can fail anyway for other reasons so it does not add much complexity to the client... But I'm probably missing something obvious: can you provide an example where not having the truncate fallback in the syscall actually break the program or introduce a bug. It's exactly what I'm looking for. Giacomo --001a113ac0cc0dcd150542865a01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2016-11-30 16:08 GMT+01:00 Charles Forsyth <charl= es.forsyth@gmail.com>:

On 30 No= vember 2016 at 15:02, Giacomo Tesio <giacomo@tesio.it> wrote:=

But reading that thread I can't actually see wh= y the OEXCL path has been taken instead of eliminating the race mapping the= syscall to the 9p message.
I mean exce= pt backward compatibility.

I suppose yo= u'll find out, but I'd expect that all but a handful of instances w= ant the existing effect and are untroubled by any potential race.
Given that OEXCL then seems to handle the handful, i= t seems a reasonable approach.
The ocreate = would just put the race in a different place, wouldn't it?

Well not exactly: I= will use the new create syscall (without OEXCL support) when I need such l= evel of control and use ocreate with OEXCL when I do not care about the rac= e and want a "create or truncate" default behaviour.

But actually, I cannot see a use case where the= create(2) default behaviour can be *wanted*.
I just see many use case = where it can be tollerated: the create can fail anyway for other reasons so= it does not add much complexity to the client...
But I'm probably m= issing something obvious: can you provide an example where not having the t= runcate fallback in the syscall actually break the program or introduce a b= ug. It's exactly what I'm looking for.


Giacomo


--001a113ac0cc0dcd150542865a01--