No! Open on an exclusive file has the same races. No problems on
Froggie .. no servers with clunk semantics. The first I encountered
was Bosch's video streamer. Nemo obviously has concerns.
Catch a run.
brucee
On Fri, Oct 29, 2010 at 10:51 AM, Gorka Guardiola wrote:
> On Thu, Oct 28, 2010 at 10
i have no idea why the yacc source wasn't included.
here it is.
- erik%{
#include
#include
#include
#include
typedef struct T T;
struct T{
T *next;
T *down;
char*s;
char*t;
int line;
char*file;
};
#pragma varargck
On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth wrote:
>
> the race is that there's nothing to say that the clunk completes before the
> process continues on to do something more, including some action that depends
> on the clunk completing,
> such as simply repeating the open. that open can fa
a number of weeks ago, to facilitate migrating many
hundreds of machines to a new network setup, i wrote a
simple and fairly bone-headed ndb database checker,
ndb/vrfy. it was amazingly effective, if provincial.
it catches all the classics like badly formatted eas,
duplicate eas, mistyped keys (
Yep. I did propose QTDECENT, and those files would have QTDECENT
set. That's what I mean.
I don't agree with your definition for decency. It's indecent [kidding ;)]
On Thu, Oct 28, 2010 at 11:22 PM, Venkatesh Srinivas
wrote:
> On Thu, Oct 28, 2010 at 4:55 PM, Nemo wrote:
>>
>> i have decent ser
> months ago, i did test an example on the system that "just works", by the way,
> and it did fail. it often takes a few attempts for it to fail,
> because it depends on scheduling (often the system completes the clunk before
> returning to the original process), but there's nothing to stop it fail
On Thu, Oct 28, 2010 at 4:55 PM, Nemo wrote:
> i have decent servers that wait for clunk to operate on written data once
> it's complete. all octopus spoolers do that.
>
>
Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid
type. I didn't mean to impugn your file servers; th
i have decent servers that wait for clunk to operate on written data once it's
complete. all octopus spoolers do that.
On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas wrote:
> On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth
> wrote:
> the race is that there's nothing to say that the clunk
On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth wrote:
> the race is that there's nothing to say that the clunk completes before the
> process continues on to do something more, including some action that
> depends on the clunk completing,
> such as simply repeating the open. that open can fail i
>Also, if that is racy, isn't this at least analogous?
i don't think so: that instance is entirely at the discretion of the programmer.
it would be analogous if the text of the program actually contained `spawn
clunk(f)',
but i was trying to represent the effects of the rewriting the system would
On Thu, Oct 28, 2010 at 8:12 AM, Charles Forsyth wrote:
> you're essentially replacing
>f := open(name, ...)
>...
>close(f)
>
> which runs as a sequential process, and subject to the usual rules for
> sequential
> composition, by
>
>f := open(name, ...)
>...
On Thu, Oct 28, 2010 at 11:53 AM, Francisco J Ballesteros wrote:
> Yes, in general, agree, but this was about clunk usage and
> semantics, and I think it's important to have the I'm done message
> synchronous when you need that.
>
> Btw, I think you mean Tstat, don't you?
> I'm not sure Twstat wou
I have used the foils package on plan9 and on osx in the past.
/n/sources/contrib/steve/foils.tgz
or
http://plan9.bell-labs.com/sources/contrib/steve/foils.tgz
-Steve
Hello,
I'm using Uriel's macros for creating slides with groff (I'm unable to
make p9p's troff to work). The slides look fine, but I can't add slide
numbers at the bottom of each slide (which I expected to get, since
the slide macros seem to modify the ms macro). I've been messing
around with troff
Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.
Btw, I think you mean Tstat, don't you?
I'm not sure Twstat would work that way in practice.
> Nowhere in the manual does it say that. The only protocol-defined way to be
> sure that you are coherent is to use Twstat with all arguments NOP. (FWIW,
> this may also be superior to checking that Tclunk did not Rerror because the
> fid is still live if Twstat Rerrors.)
name 3 in-distribution
On Thu, Oct 28, 2010 at 04:56:02PM +0200, Francisco J Ballesteros wrote:
> Be there caches of not, I've found that I want to be able to say
> "I'm done with this file, let me know if everything is done and ok".
You can, just not by using Tclunk.
> Of course, if you use 9p with no cache, you know
> Assuming messages are not reordered.
ah, the easy problems can be taken care of by using 1 clunker
and a clunk channel with a fixed buffer. i'd like to know
more about charles' correctness concerns. not that this particular
example is all that useful. cf. nemo
> My argument is that I'd like
Be there caches of not, I've found that I want to be able to say
"I'm done with this file, let me know if everything is done and ok".
Of course, if you use 9p with no cache, you know you're done if all writes
worked. If you have a cache, things may change. But either way, if you
can check at
close
On Thu, Oct 28, 2010 at 9:41 AM, Francisco J Ballesteros wrote:
> One problem I have with delayed clunks is that when you have caches or the
> like,
> close might fail. Not an issue on Inferno, but, I'd still like to be
> able to get back in sync
> at close time if only to be able to check that e
On Thu, Oct 28, 2010 at 04:00:32PM +0200, yy wrote:
>
> So, if you are using the 9vx version at
> http://bitbucket.org/yiyus/vx32/ (or ron's version, which is almost
> the same) and you have a reproducible way to crash it, could you
> please fill an issue in bitbucket or send me an email? Thanks.
One problem I have with delayed clunks is that when you have caches or the like,
close might fail. Not an issue on Inferno, but, I'd still like to be
able to get back in sync
at close time if only to be able to check that everything's ok and
safe in the server.
On Thu, Oct 28, 2010 at 4:30 PM, Go
>
> Wouldn´t a better way be?:
>
> f := open(name, ...)
> tclunk(f);
>
> spawn deallocfid(f); //and whatever needs to be done on Rclunk
>
> Hmm, it would be more like sending the Tclunk and not waiting for the
> response. That would mean
> that the fid cannot be unmarked for reuse until the respons
On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth wrote:
> you're essentially replacing
> f := open(name, ...)
> ...
> close(f)
>
> which runs as a sequential process, and subject to the usual rules for
> sequential
> composition, by
>
> f := open(name, ...)
> ..
I keep hearing how 9vx is very unstable and have a lot of problems,
but after a few months working on it I have not received many bug
reports. Probably I won't know how to fix these problems, but at least
I'd like to have them documented. Also, I'm updating the autogenerated
kernel files and would
no it is not, charles. i rarely disagree with you but the semantics
are preserved, except for changing the behaviour of existing races.
brucee
On Thu, Oct 28, 2010 at 11:12 PM, Charles Forsyth wrote:
> you're essentially replacing
> f := open(name, ...)
> ...
> close(f)
>
>
> I am guessing the io in audio does not mean in/out.
i was just changing the name to not overlap, and bacronyms are fun.
> I think audioinctl audiooutctl is a little bit more readable.
agreed.
--
All original matter is hereby placed immediately under the public domain.
On Thu, Oct 28, 2010 at 2:38 PM, Tristan Plumb <9p...@imu.li> wrote:
>>> multiple inputs or outputs? if so, my first pass would be do something
>>> like what #l does: #l0, #l1, &c.
>> Wouldn't it be better to use #A0, #A1, ... for the case of multiple
>> audio devices instead of multiple in/outs in
>> multiple inputs or outputs? if so, my first pass would be do something
>> like what #l does: #l0, #l1, &c.
> Wouldn't it be better to use #A0, #A1, ... for the case of multiple
> audio devices instead of multiple in/outs in one device?
that would make sense to me, though if there's a ethernet ca
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
...
spawn clunk(f)
which introduces a race with an invisible anon
2010/10/28 Anthony Sorace :
>> the other problem with both volume and audioctl will come with multiple
>> streams. in1 and out1 might work, but it starts to look ugly. usbaudio
>> appears to ignore multiple inputs or outputs.
>
> i'm not entirely sure what you mean by "streams" in this context. mul
31 matches
Mail list logo
