Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 7:37 AM, Bruce Ellis bruce.el...@gmail.com 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,..
Re: [9fans] A little more ado about async Tclunk
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: Topen leading to either case 1 A: Topen B: Tclunk A: Topen or case 2 A: Topen A: Topen B: Tclunk depending on the scheduling of the two processes A and B introducing that other process introduces a new race, that simply did not exist before, because that other process didn't exist before. you always got case 1. and indeed, with the test i ran on the modified system usually it gets case 1 because of timing, but eventually a case 2 shows up and the second open fails.
Re: [9fans] A little more ado about async Tclunk
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 throws a spaniard in the works. ozi2 aka casella is not ref counted but swiftly sweeps. brucee On Fri, Oct 29, 2010 at 6:44 PM, Gorka Guardiola pau...@gmail.com wrote: On Fri, Oct 29, 2010 at 7:37 AM, Bruce Ellis bruce.el...@gmail.com 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,..
Re: [9fans] A little more ado about async Tclunk
i don't believe that is possible in my implementation. will check. brucee On Fri, Oct 29, 2010 at 8:01 PM, Charles Forsyth fors...@terzarima.net 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 request to *another process* to send Tclunk ... A: Topen leading to either case 1 A: Topen B: Tclunk A: Topen or case 2 A: Topen A: Topen B: Tclunk depending on the scheduling of the two processes A and B introducing that other process introduces a new race, that simply did not exist before, because that other process didn't exist before. you always got case 1. and indeed, with the test i ran on the modified system usually it gets case 1 because of timing, but eventually a case 2 shows up and the second open fails.
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth fors...@terzarima.net 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 request to *another process* to send Tclunk ... A: Topen leading to either case 1 A: Topen B: Tclunk A: Topen or case 2 A: Topen A: Topen B: Tclunk depending on the scheduling of the two processes A and B introducing that other process introduces a new race, that simply did not exist before, because that other process didn't exist before. you always got case 1. and indeed, with the test i ran on the modified system usually it gets case 1 because of timing, but eventually a case 2 shows up and the second open fails. That is why I said, (my second message in the thread) that at least you should send the Tclunks synchronously. Meaning the close system call sends the Tclunk and then fires another thread/writes down in a list for another thread for the fid to be recollected when the answer comes asynchronously. This prevents the fid being reused and simultaneously tries to keep the operations in the order the client intended. Still there are no guarantees, because the messages can be reordered in the server but... Still, it does not work in general (the server...) and I thought it was not profitable enough to be worth the hassle, but then... 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. I haven´t read the Journal, I thought it was referring to the Dylan´s song putting froggie as an archetype of decency. You are talking about this?: http://onlinelibrary.wiley.com/doi/10.1002/bltj.1/pdf Do you do completely asynch clunks or just the wait for the response?. 10 times?, that is some latency. Can you break up exactly where the gain comes from?. G.
Re: [9fans] A little more ado about async Tclunk
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 pau...@gmail.com wrote: On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth fors...@terzarima.net 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 request to *another process* to send Tclunk ... A: Topen leading to either case 1 A: Topen B: Tclunk A: Topen or case 2 A: Topen A: Topen B: Tclunk depending on the scheduling of the two processes A and B introducing that other process introduces a new race, that simply did not exist before, because that other process didn't exist before. you always got case 1. and indeed, with the test i ran on the modified system usually it gets case 1 because of timing, but eventually a case 2 shows up and the second open fails. That is why I said, (my second message in the thread) that at least you should send the Tclunks synchronously. Meaning the close system call sends the Tclunk and then fires another thread/writes down in a list for another thread for the fid to be recollected when the answer comes asynchronously. This prevents the fid being reused and simultaneously tries to keep the operations in the order the client intended. Still there are no guarantees, because the messages can be reordered in the server but... Still, it does not work in general (the server...) and I thought it was not profitable enough to be worth the hassle, but then... 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. I haven´t read the Journal, I thought it was referring to the Dylan´s song putting froggie as an archetype of decency. You are talking about this?: http://onlinelibrary.wiley.com/doi/10.1002/bltj.1/pdf Do you do completely asynch clunks or just the wait for the response?. 10 times?, that is some latency. Can you break up exactly where the gain comes from?. G.
Re: [9fans] A little more ado about async Tclunk
On 28 October 2010 21:18, Charles Forsyth fors...@terzarima.net 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 mode or the name imposes particular constraints; constraints that depend on the order of events as expressed by the process. in practise, there is no race if the tree is being imported via plan9's exportfs(4) because it services clunk requests synchronously. on the other hand inferno's sys-export(2) services all requests (except Tflush) asynchronously, so the race will always be present. when importing a file server directly, the presence of the race will naturally depend on the file server's implementation. so this trick is unsafe in general, but might be ok sometimes.
Re: [9fans] A little more ado about async Tclunk
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
[9fans] What USB audio device are you using?
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
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 4:01 AM, Charles Forsyth fors...@terzarima.net 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 request to *another process* to send Tclunk ... A: Topen leading to either case 1 A: Topen B: Tclunk A: Topen or case 2 A: Topen A: Topen B: Tclunk depending on the scheduling of the two processes A and B introducing that other process introduces a new race, that simply did not exist before, because that other process didn't exist before. you always got case 1. and indeed, with the test i ran on the modified system usually it gets case 1 because of timing, but eventually a case 2 shows up and the second open fails. Just to make sure I understand things correctly, where does this mess things up with standard (as opposed to synthetic) file systems? ORCLOSE? OEXCL? Or is the primary concern the data flushing effect implicit in clunk? I'm inclined to agree with what I think gorka's stance is, send the clunk, but have an option to asynchronously gather the response (or make that the default and the option would be to synchronously wait for the response (waitfd(2)?) That would allow apps that really care about the data sync semantics (or oexcl, etc.) to make sure things have proceeded as planned, but wouldn't hold up the 99% of other apps that don't give a care. I guess my concern is that the always synchronous clunk for race-less semantics is simple, but if we really are giving up a big chunk of performance for the majority of uses and users, then it begs re-evaluation of the approach. -eric
Re: [9fans] A little more ado about async Tclunk
On 29 October 2010 15:14, Eric Van Hensbergen eri...@gmail.com 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 file systems. perhaps if there was, then optimisations like this could work a little less haphazardly.
Re: [9fans] A little more ado about async Tclunk
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
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 10:21 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 15:14, Eric Van Hensbergen eri...@gmail.com 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 file systems. perhaps if there was, then optimisations like this could work a little less haphazardly. Yeah, that was sort of a baseline assumption for me. Most of the synthetic file servers are susceptible to problems from such short cuts (although as Brucee points out, that depends on the short-cut and the file server). However, in many cases those servers don't need particularly high performance. It would be nice to have a system/protocol capable of satisfying both design points. Perhaps pi-p could provide such flexibility, perhaps it would need to be something else. -eric
Re: [9fans] A little more ado about async Tclunk
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.
Re: [9fans] A little more ado about async Tclunk
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).
Re: [9fans] A little more ado about async Tclunk
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.)
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 10:49 AM, Charles Forsyth fors...@terzarima.net 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 system. correct, it seems to have caused confusion all around. Perhaps s/standard/disk/g -eric
Re: [9fans] A little more ado about async Tclunk
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 process know when the operation has actually been completed prevents it from communicating that to another process, but on the other hand, with the existing constructions, it can't find out.
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 5:01 AM, Charles Forsyth fors...@terzarima.netwrote: 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: Topen leading to either case 1 A: Topen B: Tclunk A: Topen or case 2 A: Topen A: Topen B: Tclunk depending on the scheduling of the two processes A and B introducing that other process introduces a new race, that simply did not exist before, because that other process didn't exist before. you always got case 1. and indeed, with the test i ran on the modified system usually it gets case 1 because of timing, but eventually a case 2 shows up and the second open fails. Correct. Either ordering is reasonable and not-a-problem when dealing with a decent fileserver. There are certainly file servers and open options that force single-open, but this approach is not for them. -- vs
Re: [9fans] A little more ado about async Tclunk
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 eri...@gmail.com wrote: On Fri, Oct 29, 2010 at 10:49 AM, Charles Forsyth fors...@terzarima.net 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 system. correct, it seems to have caused confusion all around. Perhaps s/standard/disk/g -eric
Re: [9fans] A little more ado about async Tclunk
On 29 October 2010 17:01, Charles Forsyth fors...@terzarima.net 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 reason, though i didn't look at the diffs, i thought that's what this patch did. even sending Tclunk synchronously is still problematic in quite a few scenarios, for the reasons i outlined above.
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 12:01 PM, Charles Forsyth fors...@terzarima.netwrote: 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
Re: [9fans] A little more ado about async Tclunk
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 rogpe...@gmail.com wrote: On 29 October 2010 17:01, Charles Forsyth fors...@terzarima.net 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 reason, though i didn't look at the diffs, i thought that's what this patch did. even sending Tclunk synchronously is still problematic in quite a few scenarios, for the reasons i outlined above.
Re: [9fans] A little more ado about async Tclunk
i don't believe that is possible in my implementation. will check. it was your implementation i was testing.
Re: [9fans] A little more ado about async Tclunk
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 change, that is no longer true, even for a single (visible) process.
Re: [9fans] A little more ado about async Tclunk
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 logic, in the form of QTCTL) said this about indecent files: this file does not behave like a regular file, do not cache and handle with care. I think stating it in the form: indecent files require in-order issue _and_ completion of a 9p request stream from the perspective of the application making the system calls/generating 9p messages to the file service. There is a loose convention now of qid.version == 0 meaning something like 'indecent'. roger, charles describe races in both async TClunk issue and async RClunk wait: r1 := A: sekrit B: TOpen(name, ...) spawn TClunk TOpen(name, ...) TClunk(fid..) RClunk(yep! / nope!) ... Perhaps I'm being really thick, but this is the same scenario as a current: A:explicit process B: -TOpen(name, ...) - ROpen(yea) - TOpen(name, ...) - ROpen(zzz) - TClunk(fid) - RClunk(fid) ... zzz := Yes, of course, on a 'decent' fileserver; 'no' on an indecent one, or with OEXCL in A's open. All the asynchronous issue opens is this concurrency issue with yourself (A against itself)... but it already exists if you don't use OEXCL in the (A against B) form. On Fri, Oct 29, 2010 at 11:59 AM, Bruce Ellis bruce.el...@gmail.com wrote: 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 When you get a chance, could you describe your approach in more detail? Bruce Ellis also wrote: Roger Peppe wrote: even sending Tclunk synchronously is still problematic in quite a few scenarios, for the reasons i outlined above. 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. Sorry, I don't see the embrace... when the original close() caller doesn't wait on the TClunk/RClunk pair, what would it stall on? What would the close process stall on? Thanks! -- vs
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 8:49 AM, Charles Forsyth fors...@terzarima.netwrote: 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. All file systems are synthetic, some are backed by disk blocks, or other goo. File systems are nothing more than a namespace abstraction on X, where you get to decide what X is if you're implementing one. This is what I've been trying to communicate to my software development teams last year, and they very nearly got it :-). I think functional programming or at least category theory gets you into these upper level abstract ways of thinking that help with making such nonsense into sense. (I'm not sure that last sentence really parses, but since I've lost my backspace key, there it is) Dave
Re: [9fans] A little more ado about async Tclunk
On 29 October 2010 17:17, Bruce Ellis bruce.el...@gmail.com 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 Rclunk as by processing the whole clunk message asychronously?
Re: [9fans] A little more ado about async Tclunk
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?
Re: [9fans] A little more ado about async Tclunk
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, ... unfortunately, fossil and kfs both can have important visible state changes on a clunk, so that lets them out.
Re: [9fans] A little more ado about async Tclunk
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 file does not behave like a regular file, do not cache and handle with care. unfortunately, unless you are talking about archival storage (e.g., /n/dump), i think the difference between a decent file and a ctl file starts to seem slippery. unless a file is exclusive open it's hard to be sure that a file won't change underneath you. - erik
Re: [9fans] A little more ado about async Tclunk
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 servers we can think of that are 'decent': fossil, kfs, ken, memfs, ... unfortunately, fossil and kfs both can have important visible state changes on a clunk, so that lets them out. i think we're reducing this down to it's easy to cache the hell out of immutable files. - erik
Re: [9fans] A little more ado about async Tclunk
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
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 10:13 AM, Charles Forsyth fors...@terzarima.netwrote: 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 say the act of moving a problem between languages can shed some light from time to time. Category Theory really doesn't say too much in general, but oddly enough it applies nicely to computer science. What's that mean? :-)
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 10:17 AM, erik quanstrom quans...@labs.coraid.comwrote: 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 servers we can think of that are 'decent': fossil, kfs, ken, memfs, ... unfortunately, fossil and kfs both can have important visible state changes on a clunk, so that lets them out. i think we're reducing this down to it's easy to cache the hell out of immutable files. Well that's like memoization of a pure function. The answer is yes, because if the output of a function doesn't change when the same input is applied, the function is just a table lookup anyway. Same should hold true for immutable files and the operations available on them not being able to change the state. When dependent state doesn't change, concurrency is easier to get right. Dave - erik
Re: [9fans] A little more ado about async Tclunk
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 quans...@quanstro.net 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
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 12:18 PM, Charles Forsyth 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 servers we can think of that are 'decent': fossil, kfs, ken, memfs, ... unfortunately, fossil and kfs both can have important visible state changes on a clunk, so that lets them out. qid.vers? What else? What % of apps depend on the visible stage change? Sorry - I'm not really trying to be an ass (even though I may be succeeding), I'm just trying to get an idea of the actual negative impact. I imagine if I made this change in v9fs for Linux servers I wouldn't see any negative behavior at all. -eric
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 10:26 AM, erik quanstrom quans...@quanstro.netwrote: 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 something concrete was last weekend when I wore to nasty blisters into my hands debarking about 170 feet of 18 inch logs for a structure to camp under year round. Computer software doesn't often leave one with much to stand back and admire. At least not so much that non-software people can appreciate with you :-). Sometimes it's nice to do things less abstract. Dave
Re: [9fans] A little more ado about async Tclunk
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, Decent meant cacheable. Your meaning as nemo said... not so decent. cacheable != clunk is nop even further cacheable != clunk can be processed asynchronously. Both concepts are orthogonal. Cathegory theory is useful for thinking about topology and other things. It is not abstract nonsense, only abstract. It *is* noise in this thread though.
Re: [9fans] A little more ado about async Tclunk
On Fri, Oct 29, 2010 at 11:54 AM, Gorka Guardiola pau...@gmail.com 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 servers we can think of that are 'decent': fossil, kfs, ken, Decent meant cacheable. Your meaning as nemo said... not so decent. cacheable != clunk is nop even further cacheable != clunk can be processed asynchronously. Both concepts are orthogonal. It might be more useful to think of it in terms of what it *does* mean. Asynchronous clunkableness == no dependencies on ordering of clunk processing to the next open call? Cacheability can mean a lot of stuff depending on what is being cached, and how such a cache becomes invalidated and refreshed. I agree it's orthogonal. Cathegory theory is useful for thinking about topology and other things. It is not abstract nonsense, only abstract. It *is* noise in this thread though. It's tangentially related to an off to the side comment about cacheability. But yes it's definitely noise :-).
Re: [9fans] A little more ado about async Tclunk
On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com 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?
Re: [9fans] A little more ado about async Tclunk
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, Decent meant cacheable. Your meaning as nemo said... not so decent. cacheable != clunk is nop even further cacheable != clunk can be processed asynchronously. Both concepts are orthogonal. that's sort of recursively begging the question. cachable in what sense? Cathegory theory is useful for thinking about topology and other things. It is not abstract nonsense, only abstract. It *is* noise in this thread though. at the risk of the explaination devolving into general abstract nonsense, ... in the english literature, category theory is often refered to as abstract nonsense. it's a mathematician joke, and a complement, that i thought would be appreciated here. http://en.wikipedia.org/wiki/Abstract_nonsense - erik
Re: [9fans] A little more ado about async Tclunk
back to school for roger On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com 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?
Re: [9fans] A little more ado about async Tclunk
On Oct 29, 2010, at 10:27 PM, Bruce Ellis bruce.el...@gmail.com wrote: back to school for roger On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com 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? I need to go back to school with him too. http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html Unless it is again some obscure reference...
Re: [9fans] A little more ado about async Tclunk
that definition is wrong! On Sat, Oct 30, 2010 at 7:41 AM, Gorka Guardiola pau...@gmail.com wrote: On Oct 29, 2010, at 10:27 PM, Bruce Ellis bruce.el...@gmail.com wrote: back to school for roger On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com 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? I need to go back to school with him too. http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html Unless it is again some obscure reference...
[9fans] replica/pull as of today
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
Re: [9fans] replica/pull as of today
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
Re: [9fans] replica/pull as of today
They are defined in port/devmouse.c. Did you get an updated beagle config file when you pulled? You should have.
Re: [9fans] replica/pull as of today
On Fri, Oct 29, 2010 at 2:52 PM, ge...@plan9.bell-labs.com 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
Re: [9fans] replica/pull as of today
On Fri, Oct 29, 2010 at 2:58 PM, ron minnich rminn...@gmail.com wrote: On Fri, Oct 29, 2010 at 2:52 PM, ge...@plan9.bell-labs.com 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
Re: [9fans] replica/pull as of today
OK had to uncomment the mouse in the devs, and all was well. ron
Re: [9fans] replica/pull as of today
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
Re: [9fans] replica/pull as of today
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
Re: [9fans] A little more ado about async Tclunk
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 Bruce Ellis bruce.el...@gmail.com wrote: that definition is wrong! On Sat, Oct 30, 2010 at 7:41 AM, Gorka Guardiola pau...@gmail.com wrote: On Oct 29, 2010, at 10:27 PM, Bruce Ellis bruce.el...@gmail.com wrote: back to school for roger On Sat, Oct 30, 2010 at 6:33 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 18:47, Bruce Ellis bruce.el...@gmail.com 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 embrac e? I need to go back to school with him too. http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace .html Unless it is again some obscure reference...
Re: [9fans] A little more ado about async Tclunk
On 29 October 2010 21:44, Bruce Ellis bruce.el...@gmail.com wrote: that definition is wrong! so point us to the right one then.
Re: [9fans] A little more ado about async Tclunk
grab a book by hoare or morgan. brucee On Sat, Oct 30, 2010 at 9:39 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 21:44, Bruce Ellis bruce.el...@gmail.com wrote: that definition is wrong! so point us to the right one then.
Re: [9fans] A little more ado about async Tclunk
the only book by hoare i've got (CSP) doesn't mention a deadly embrace. On 29 October 2010 23:43, Bruce Ellis bruce.el...@gmail.com wrote: grab a book by hoare or morgan. brucee On Sat, Oct 30, 2010 at 9:39 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 21:44, Bruce Ellis bruce.el...@gmail.com wrote: that definition is wrong! so point us to the right one then.
Re: [9fans] A little more ado about async Tclunk
well you need more books. On Sat, Oct 30, 2010 at 10:07 AM, roger peppe rogpe...@gmail.com wrote: the only book by hoare i've got (CSP) doesn't mention a deadly embrace. On 29 October 2010 23:43, Bruce Ellis bruce.el...@gmail.com wrote: grab a book by hoare or morgan. brucee On Sat, Oct 30, 2010 at 9:39 AM, roger peppe rogpe...@gmail.com wrote: On 29 October 2010 21:44, Bruce Ellis bruce.el...@gmail.com wrote: that definition is wrong! so point us to the right one then.
