From: "Fco. J. Ballesteros" <nemo@lsub.org>
To: russcox@gmail.com, 9fans@cse.psu.edu
Subject: Re: [9fans] rio snarf
Date: Wed, 27 Oct 2004 19:57:38 +0200 [thread overview]
Message-ID: <065a179f8cfb563bc08c13be9dfc5359@plan9.escet.urjc.es> (raw)
In-Reply-To: <ee9e417a04102710516945fe9e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
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
[-- Attachment #2: Type: message/rfc822, Size: 4005 bytes --]
From: Russ Cox <russcox@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] rio snarf
Date: Wed, 27 Oct 2004 13:51:10 -0400
Message-ID: <ee9e417a04102710516945fe9e@mail.gmail.com>
> 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
prev parent reply other threads:[~2004-10-27 17:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-27 11:16 Fco. J. Ballesteros
2004-10-27 17:10 ` Russ Cox
2004-10-27 17:31 ` Fco. J. Ballesteros
2004-10-27 17:51 ` Russ Cox
2004-10-27 17:57 ` Fco. J. Ballesteros [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=065a179f8cfb563bc08c13be9dfc5359@plan9.escet.urjc.es \
--to=nemo@lsub.org \
--cc=9fans@cse.psu.edu \
--cc=russcox@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).