On Fri, Oct 29, 2010 at 7:37 AM, Bruce Ellis wrote:
> No! Open on an exclusive file has the same races. No problems on
I said I agree it is a problem. Yes, there is a race... Froggie?
A lily-white duck come and swallowed him up,..
>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
A: Topen
...
queue request to *another process* to send Tclunk
...
A: T
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.
the only server that i saw at the labs that had Rclunk semantics was
pb's video magic which i i didn't need. nemo th
i don't believe that is possible in my implementation. will check.
brucee
On Fri, Oct 29, 2010 at 8:01 PM, Charles Forsyth wrote:
>>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
On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth wrote:
>>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
> A: Topen
> ...
> queue
right journal. i'll do some unusual tests and report on the results.
wing-commander has to awake early to attend his mother's 80th birthday party.
back to you on this one.
brucee
On Fri, Oct 29, 2010 at 8:45 PM, Gorka Guardiola wrote:
> On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth
> wro
On 28 October 2010 21:18, 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 if the
On Fri, Oct 29, 2010 at 02:12:11PM +0100, roger peppe wrote:
>
> so this trick is unsafe in general, but might be ok sometimes.
So is the answer to add semantics to Topen or add a Treopen that obviates
the Tclunk?
++L
Here's an open question to anyone using USB audio on Plan 9: What
device are you using? How well does it work?
I'm looking for something I can get on Amazon; my T22 has been silent
long enough!
John
On Fri, Oct 29, 2010 at 4:01 AM, Charles Forsyth wrote:
>>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
> A: Topen
> ...
> queue
On 29 October 2010 15:14, Eric Van Hensbergen wrote:
> Just to make sure I understand things correctly, where does this mess
> things up with standard (as opposed to synthetic) file systems?
i think that part of the problem is that plan 9 makes no distinction
between "standard" and "synthetic" fi
> i think that part of the problem is that plan 9 makes no distinction
> between "standard" and "synthetic" file systems.
>
> perhaps if there was, then optimisations like this could
> work a little less haphazardly.
what's a reasonable definition of "standard"?
- erik
On Fri, Oct 29, 2010 at 10:21 AM, roger peppe wrote:
> On 29 October 2010 15:14, Eric Van Hensbergen wrote:
>> Just to make sure I understand things correctly, where does this mess
>> things up with standard (as opposed to synthetic) file systems?
>
> i think that part of the problem is that plan
> things up with standard (as opposed to synthetic) file systems?
why should a "synthetic" file system (actually they are all synthetic, i think)
be considered not "standard"? i thought file systems were the common currency
in the system.
>in practise, there is no race if the tree is being imported via
>plan9's exportfs(4)
>because it services clunk requests synchronously.
there is indeed a race because another process is issuing the clunk(s),
not the one that's doing the open(s).
>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 probab
On Fri, Oct 29, 2010 at 10:49 AM, Charles Forsyth wrote:
>> things up with standard (as opposed to synthetic) file systems?
>
> why should a "synthetic" file system (actually they are all synthetic, i
> think)
> be considered not "standard"? i thought file systems were the common currency
> in t
>having the original process send the Tclunk and not wait
>for the Rclunk is different.
ah. having thought about it, i see it's different only in the case of
one process. it isn't different if you have several processes that are
trying to co-operate in an allowed way: failing to let the issuing
pr
On Fri, Oct 29, 2010 at 5:01 AM, Charles Forsyth wrote:
> >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
>A: Topen
>...
>qu
this discussion was more interesting in thev UNIX room. froggie hasn't
hung up yet thru a serious thrashing this evening - and all the FSs
are synthetic - it has no disk.
as much as i like philosophizing that's not my way.
brucee
On Sat, Oct 30, 2010 at 2:50 AM, Eric Van Hensbergen wrote:
> On
On 29 October 2010 17:01, 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.
for some reas
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 thi
gee i thought i was the first to say deadly-embrace on this thread.
it's not only problematic it's wrong. just reiterating what little
shaun said circa 1999.
brucee
On Sat, Oct 30, 2010 at 3:02 AM, roger peppe wrote:
> On 29 October 2010 17:01, Charles Forsyth wrote:
>>>Do you do completely asy
>i don't believe that is possible in my implementation. will check.
it was your implementation i was testing.
>on the other hand inferno's sys-export(2) services all requests
>(except Tflush) asynchronously,
>so the race will always be present.
no, that mistakes the problem. without the change, the issuing process
will see the clunk completed before it attempts any further operations:
no race. with the ch
erik quanstrom wrote:
> what's a reasonable definition of "standard"?
I've been using 'decent' in much the same way 'standard' or 'disk' is being
used; I'd actually prefer nemo's idea of a QTDECENT qidtype to marking the
file server. The original QTDECENT proposal (actually originally inverted
log
On Fri, Oct 29, 2010 at 8:49 AM, Charles Forsyth wrote:
> > things up with standard (as opposed to synthetic) file systems?
>
> why should a "synthetic" file system (actually they are all synthetic, i
> think)
> be considered not "standard"? i thought file systems were the common
> currency in the
On 29 October 2010 17:17, Bruce Ellis wrote:
> gee i thought i was the first to say deadly-embrace on this thread.
> it's not only problematic it's wrong. just reiterating what little
> shaun said circa 1999.
if deadlock is the issue, isn't it solved just as well
by asynchronously receiving the R
>I think functional programming or at least category theory gets you into
>these upper level abstract ways of thinking
uh oh. is there an analogy to Godwin's Law for mentioning category theory?
> Let's try to define 'decent' for this thread -- a decent fileserver is one
> on which close()s do not have any client-visible or semantic effect other
> than to invalidate the Fid that was passed to them. Lets see how many file
> servers we can think of that are 'decent': fossil, kfs, ken, memfs,
> I've been using 'decent' in much the same way 'standard' or 'disk' is being
> used; I'd actually prefer nemo's idea of a QTDECENT qidtype to marking the
> file server. The original QTDECENT proposal (actually originally inverted
> logic, in the form of QTCTL) said this about indecent files: "this
On Fri Oct 29 13:15:45 EDT 2010, fors...@terzarima.net wrote:
> > Let's try to define 'decent' for this thread -- a decent fileserver is one
> > on which close()s do not have any client-visible or semantic effect other
> > than to invalidate the Fid that was passed to them. Lets see how many file
>
> Category Theory really doesn't say too much in general, but oddly enough it
> applies nicely to computer science. What's that mean? :-)
that they're both abstract nonsense.
- erik
On Fri, Oct 29, 2010 at 10:13 AM, Charles Forsyth wrote:
> >I think functional programming or at least category theory gets you into
> >these upper level abstract ways of thinking
>
> uh oh. is there an analogy to Godwin's Law for mentioning category theory?
>
> I hope not... I'm merely trying to
On Fri, Oct 29, 2010 at 10:17 AM, erik quanstrom
wrote:
> On Fri Oct 29 13:15:45 EDT 2010, fors...@terzarima.net wrote:
> > > Let's try to define 'decent' for this thread -- a decent fileserver is
> one
> > > on which close()s do not have any client-visible or semantic effect
> other
> > > than to
who said deadlock. it's an easily reproducible situation. rattle the
cage is not a solution.
brucee
On Sat, Oct 30, 2010 at 4:26 AM, erik quanstrom wrote:
>> Category Theory really doesn't say too much in general, but oddly enough it
>> applies nicely to computer science. What's that mean? :-)
On Fri, Oct 29, 2010 at 12:18 PM, Charles Forsyth wrote:
>> Let's try to define 'decent' for this thread -- a decent fileserver is one
>> on which close()s do not have any client-visible or semantic effect other
>> than to invalidate the Fid that was passed to them. Lets see how many file
>> serve
On Fri, Oct 29, 2010 at 10:26 AM, erik quanstrom wrote:
> > Category Theory really doesn't say too much in general, but oddly enough
> it
> > applies nicely to computer science. What's that mean? :-)
>
> that they're both abstract nonsense.
>
> - erik
>
>
Yeah... the most fun I had making somethi
>> Let's try to define 'decent' for this thread -- a decent fileserver is one
>> on which close()s do not have any client-visible or semantic effect other
>> than to invalidate the Fid that was passed to them. Lets see how many file
>> servers we can think of that are 'decent': fossil, kfs, ken,
On Fri, Oct 29, 2010 at 11:54 AM, Gorka Guardiola wrote:
>
> >> Let's try to define 'decent' for this thread -- a decent fileserver is
> one
> >> on which close()s do not have any client-visible or semantic effect
> other
> >> than to invalidate the Fid that was passed to them. Lets see how many
On 29 October 2010 18:47, Bruce Ellis wrote:
> who said deadlock. it's an easily reproducible situation. rattle the
> cage is not a solution.
sorry then, i misunderstood you. what else did you mean by "deadly embrace"?
> >> Let's try to define 'decent' for this thread -- a decent fileserver is one
> >> on which close()s do not have any client-visible or semantic effect other
> >> than to invalidate the Fid that was passed to them. Lets see how many file
> >> servers we can think of that are 'decent': fossil, kfs,
back to school for roger
On Sat, Oct 30, 2010 at 6:33 AM, roger peppe wrote:
> On 29 October 2010 18:47, Bruce Ellis wrote:
>> who said deadlock. it's an easily reproducible situation. rattle the
>> cage is not a solution.
>
> sorry then, i misunderstood you. what else did you mean by "deadly em
On Oct 29, 2010, at 10:27 PM, Bruce Ellis wrote:
> back to school for roger
>
> On Sat, Oct 30, 2010 at 6:33 AM, roger peppe wrote:
>> On 29 October 2010 18:47, Bruce Ellis wrote:
>>> who said deadlock. it's an easily reproducible situation. rattle the
>>> cage is not a solution.
>>
>> sorry
that definition is wrong!
On Sat, Oct 30, 2010 at 7:41 AM, Gorka Guardiola wrote:
>
> On Oct 29, 2010, at 10:27 PM, Bruce Ellis wrote:
>
>> back to school for roger
>>
>> On Sat, Oct 30, 2010 at 6:33 AM, roger peppe wrote:
>>> On 29 October 2010 18:47, Bruce Ellis wrote:
who said deadlock
trying to build an omap, I get a missing mousexy and mouseresize in
libdraw. They are indeed not there at least in what I pulled. Any
hints here?
ron
> trying to build an omap, I get a missing mousexy and mouseresize in
> libdraw. They are indeed not there at least in what I pulled. Any
> hints here?
I had exactly the same problem.
--
David du Colombier
They are defined in port/devmouse.c. Did you get an updated
beagle config file when you pulled? You should have.
On Fri, Oct 29, 2010 at 2:52 PM, wrote:
> They are defined in port/devmouse.c.
there is no port/devmouse.c in my tree. Pull just done a few minutes ago.
ron
On Fri, Oct 29, 2010 at 2:58 PM, ron minnich wrote:
> On Fri, Oct 29, 2010 at 2:52 PM, wrote:
>> They are defined in port/devmouse.c.
>
>
> there is no port/devmouse.c in my tree. Pull just done a few minutes ago.
arg. no wait there is.
Hold on.
ron
OK had to uncomment the mouse in the devs, and all was well.
ron
> They are defined in port/devmouse.c. Did you get an updated
> beagle config file when you pulled? You should have.
No. It seems the problem is there.
--
David du Colombier
> OK had to uncomment the mouse in the devs, and all was well.
It seems the replica database is not fully up to date, since the file
/sys/src/9/omap/beagle contains the uncommented mouse on sources.
--
David du Colombier
See EWD108 "Een algorithme ter voorkoming van de dodelijke
omarming." (An algorithm to avoid the deadly embrace.) in
which Dijkstra describes his Bankers algorithm. 1965 or
earlier. Of course, you may be looking at deadly embrace
from a different point of view.
On Sat, 30 Oct 2010 07:44:58 +1100
On 29 October 2010 21:44, Bruce Ellis wrote:
> that definition is wrong!
so point us to the right one then.
grab a book by hoare or morgan.
brucee
On Sat, Oct 30, 2010 at 9:39 AM, roger peppe wrote:
> On 29 October 2010 21:44, Bruce Ellis wrote:
>> that definition is wrong!
>
> so point us to the right one then.
>
>
the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
On 29 October 2010 23:43, Bruce Ellis wrote:
> grab a book by hoare or morgan.
>
> brucee
>
> On Sat, Oct 30, 2010 at 9:39 AM, roger peppe wrote:
>> On 29 October 2010 21:44, Bruce Ellis wrote:
>>> that definition is wrong!
well you need more books.
On Sat, Oct 30, 2010 at 10:07 AM, roger peppe wrote:
> the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
>
> On 29 October 2010 23:43, Bruce Ellis wrote:
>> grab a book by hoare or morgan.
>>
>> brucee
>>
>> On Sat, Oct 30, 2010 at 9:39 AM, roger p
58 matches
Mail list logo
