From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <065a179f8cfb563bc08c13be9dfc5359@plan9.escet.urjc.es> From: "Fco. J. Ballesteros" Date: Wed, 27 Oct 2004 19:57:38 +0200 To: russcox@gmail.com, 9fans@cse.psu.edu Subject: Re: [9fans] rio snarf In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-fcwnkjpsguuzyzcesbtfnxpeno" Cc: Topicbox-Message-UUID: f782f3c0-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-fcwnkjpsguuzyzcesbtfnxpeno Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Well, having a /dev/snarf created by, say, binding /tmp/blah to /dev/snarf does not seem to work, because rio ends up leaving the biggest thing that was in there (because it does not truncate the file). I think it assumes that the behaviour of /dev/snarf is that of rio's, and not that of a regular file. Regarding the question, I think you answered it. I understand it provides a snarf if you have different per-rio snarf files. thanks --upas-fcwnkjpsguuzyzcesbtfnxpeno Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Wed Oct 27 19:51:31 MDT 2004 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id D117063FDB for ; Wed, 27 Oct 2004 13:51:22 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id F3E7963E41 for <9fans@cse.psu.edu>; Wed, 27 Oct 2004 13:51:13 -0400 (EDT) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22046-01-40 for <9fans@cse.psu.edu>; Wed, 27 Oct 2004 13:51:11 -0400 (EDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 87AD831E9B for <9fans@cse.psu.edu>; Wed, 27 Oct 2004 13:51:11 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 68so345653wri for <9fans@cse.psu.edu>; Wed, 27 Oct 2004 10:51:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nuoqaJhK9AzEBU5+xT5k3U9ECnMZ5sOzVpa4LO7L2SmLk1RSJGpGBPaTmhd6ZjZLVdWdCuI0AymxzBIJ+dJuZO2OSQ3l7+aT4ZfiB5ul3J5KkP2THdrS3b42B/dOdJ2e8RZ5T3YwN7SXyw+gMF/fFp3k8IXArnhcuVFIbCfpamg= Received: by 10.38.15.14 with SMTP id 14mr1309816rno; Wed, 27 Oct 2004 10:51:11 -0700 (PDT) Received: by 10.38.65.22 with HTTP; Wed, 27 Oct 2004 10:51:10 -0700 (PDT) Message-ID: Date: Wed, 27 Oct 2004 13:51:10 -0400 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] rio snarf In-Reply-To: <75959811c030beb33eb82d0460fcd6ca@plan9.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <75959811c030beb33eb82d0460fcd6ca@plan9.escet.urjc.es> X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ Cox , Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+nemo=lsub.org@cse.psu.edu Errors-To: 9fans-bounces+nemo=lsub.org@cse.psu.edu > Well. We just found that removing snarf from rio fsys makes things > work great wrt sharing the snarf buffer across machines. If that's all you want to do, just create a /dev/snarf before rio runs -- if it sees one already there, it won't provide one. > At first, we thought that if was enough to call open(OTRUNC) while > copying to the snarf buffer, then we noticed the deadlock with the > open("/dev/snarf") in rio, then we tried removing snarf from rio, and, > voila. This I still don't fully understand. The reason the snarf buffer doesn't change until close is probably lost to history, but one nice effect is that updating the snarf buffer is atomic -- you'll never see a partially written one. > Either I'm crazy because of the lots of coffee I have been drinking, or > there is something I'm missing regarding why rio has snarf builtin instead > of using a regular file for that. Rio used to provide a separate snarf buffer for each instance of rio. It's only recently that there has been this push toward having one snarf buffer for the whole system. Russ --upas-fcwnkjpsguuzyzcesbtfnxpeno--