From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 29 Oct 2010 11:45:16 +0200 Message-ID: From: Gorka Guardiola To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] A little more ado about async Tclunk Topicbox-Message-UUID: 71138756-ead6-11e9-9d60-3106f5b1d025 On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth w= rote: >>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 > =A0 =A0 =A0 =A0A: Topen > =A0 =A0 =A0 =A0... > =A0 =A0 =A0 =A0queue request to *another process* to send Tclunk > =A0 =A0 =A0 =A0... > =A0 =A0 =A0 =A0A: Topen > > leading to either case 1 > =A0 =A0 =A0 =A0A: Topen > =A0 =A0 =A0 =A0B: Tclunk > =A0 =A0 =A0 =A0A: Topen > > or case 2 > =A0 =A0 =A0 =A0A: Topen > =A0 =A0 =A0 =A0A: Topen > =A0 =A0 =A0 =A0B: 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 ca= se 1 > because of timing, but eventually a case 2 shows up and the second open f= ails. > > That is why I said, (my second message in the thread) that at least you should send the Tclunks synchronously. Meaning the close system call sends the Tclunk and then fires another thread/writes down in a list for another thread for the fid to be recollected when the answer comes asynchronously. This prevents the fid being reused and simultaneously tries to keep the operations in the order the client intended. Still there are no guarantees, because the messages can be reordered in the server but... Still, it does not work in general (the server...) and I thought it was not profitable enough to be worth the hassle, but then... > my froggie has been running for four years 24/7. if you haven't read > the BLTJ then styx runs over the PCI ... 4 ixp1200s. asynch clunks. > the only problem is it's 10 times quicker. I haven=B4t read the Journal, I thought it was referring to the Dylan=B4s s= ong putting froggie as an archetype of decency. You are talking about this?: http://onlinelibrary.wiley.com/doi/10.1002/bltj.1/pdf Do you do completely asynch clunks or just the wait for the response?. 10 times?, that is some latency. Can you break up exactly where the gain comes from?. G.