Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread hiro
also read what has been written before about fcp. and read the source of fcp. On 10/14/18, Ole-Hjalmar Kristensen wrote: > OK, that makes sense. So it would not stop a client from for example first > read an index block in a B-tree, wait for the result, and then issue read > operations for all

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread Ole-Hjalmar Kristensen
OK, that makes sense. So it would not stop a client from for example first read an index block in a B-tree, wait for the result, and then issue read operations for all the data blocks in parallel. That's exactly the same as any asynchronous disk subsystem I am acquainted with. Reordering is the

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread hiro
there's no tyranny involved. a client that is fine with the *responses* coming in reordered could remember the tag obviously and do whatever you imagine. the problem is potential reordering of the messages in the kernel before responding, even if the 9p transport has guaranteed ordering. On

Re: [9fans] PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread Ole-Hjalmar Kristensen
I'm not going to argue with someone who has got his hands dirty by actually doing this but I don't really get this about the tyranny of 9p. Isn't the point of the tag field to identify the request? What is stopping the client from issuing multiple requests and match the replies based on the tag?

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread hiro
thanks, this will allow us to know where to look more closely. On 10/14/18, Francisco J Ballesteros wrote: > Pure "producer/cosumer" stuff, like sending things through a pipe as long as > the source didn't need to touch the data ever more. > Regarding bugs, I meant "producing bugs" not "fixing

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread Francisco J Ballesteros
Pure "producer/cosumer" stuff, like sending things through a pipe as long as the source didn't need to touch the data ever more. Regarding bugs, I meant "producing bugs" not "fixing bugs", btw. > On 14 Oct 2018, at 09:34, hiro <23h...@gmail.com> wrote: > > well, finding bugs is always good :) >

Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!)

2018-10-14 Thread hiro
well, finding bugs is always good :) but since i got curious could you also tell which things exactly got much faster, so that we know what might be possible? On 10/14/18, FJ Ballesteros wrote: > yes. bugs, on my side at least. > The copy isolates from others. > But some experiments in nix and