From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <dbb7239e8c352e8db20ca68c849e381a@terzarima.net>
From: Charles Forsyth <forsyth@terzarima.net>
Date: Fri, 29 Oct 2010 10:01:02 +0100
To: 9fans@9fans.net
In-Reply-To: <AANLkTikX=TOj5_k8mG88O0Lfnb-uGDK6BzkuMZqGACzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] A little more ado about async Tclunk
Topicbox-Message-UUID: 70fccf2a-ead6-11e9-9d60-3106f5b1d025

>What you are saying is that the problem could be something like:

>-> Tclunk
>(do not wait for response)
>-> Topen (the file is exclusive)

no, because what actually happens is closer to
	A: Topen
	...
	queue request to *another process* to send Tclunk
	...
	A: Topen

leading to either case 1
	A: Topen
	B: Tclunk
	A: Topen

or case 2
	A: Topen
	A: Topen
	B: Tclunk

depending on the scheduling of the two processes A and B

introducing that other process introduces a new race, that simply did not exist before, because
that other process didn't exist before. you always got case 1.

and indeed, with the test i ran on the modified system usually it gets case 1
because of timing, but eventually a case 2 shows up and the second open fails.