From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <62bde7ee0bc7ccdee84657319b0d5eb3@terzarima.net> References: <62bde7ee0bc7ccdee84657319b0d5eb3@terzarima.net> From: Venkatesh Srinivas Date: Fri, 29 Oct 2010 11:58:27 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016367fa7acab649c0493c38882 Subject: Re: [9fans] A little more ado about async Tclunk Topicbox-Message-UUID: 72026088-ead6-11e9-9d60-3106f5b1d025 --0016367fa7acab649c0493c38882 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 29, 2010 at 12:01 PM, Charles Forsyth wrote: > >Do you do completely asynch clunks or just the wait for the response?. > > it uses `completely' async clunks, which is why it can be broken. > > having the original process send the Tclunk and not wait > for the Rclunk is different. i think it was mentioned last time this > matter came up, and that's probably why i didn't pursue this discussion > further then, since that change is less of a problem. (at least, if you > don't mind > close not returning an error from the clunk, but since the current > implementations > suppress errors from clunk, it's a trickier position to sustain.) > > I think that this is a fine approach as well -- the vast majority of the performance improvement is in eliminating the wait for the Rclunk, not in the asynchronous issue. I didn't use this approach here not because I wanted to issue the clunk out-of-line, but because it was harder to code (I'd have needed to split devmnt's mountio()). This was actually the approach Wes and I did last year when commenting on the desirability of asynchronous clunks, in a purely "user mode" process. The performance gains were very similar to this work. -- vs --0016367fa7acab649c0493c38882 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 29, 2010 at 12:01 PM, Charles Forsyt= h <forsyth@te= rzarima.net> wrote:
>Do you do completely asynch clunks or just the wait f= or the response?.

it uses `completely' async clunks, which is why it can be broken.=

having the original process send the Tclunk and not wait
for the Rclunk is different. i think it was mentioned last time this
matter came up, and that's probably why i didn't pursue this discus= sion
further then, since that change is less of a problem. (at least, if you don= 't mind
close not returning an error from the clunk, but since the current implemen= tations
suppress errors from clunk, it's a trickier position to sustain.)


I think that this is a fine approach as well -- the = vast majority of the performance improvement is in eliminating the wait for= the Rclunk, not in the asynchronous issue. I didn't use this approach = here not because I wanted to issue the clunk out-of-line, but because it wa= s harder to code (I'd have needed to split devmnt's mountio()).
This was actually the approach Wes and I did last year when commenting = on the desirability of asynchronous clunks, in a purely "user mode&quo= t; process. The performance gains were very similar to this work.

-- vs
--0016367fa7acab649c0493c38882--