From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: "Fco. J. Ballesteros" Date: Thu, 23 Apr 2009 19:31:03 +0200 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] 9p2010 Topicbox-Message-UUID: f155743a-ead4-11e9-9d60-3106f5b1d025 But if you do that (send sequences from userl-level) you must interpret your namespace yourself. When I tried to detect how to bundle calls for plan b, a problem I had was namec. For me it's still not clear how to detect cleanly `what to batch', even if you change the source for the program doing I/O to help there, because of the mount table. > From: rogpeppe@gmail.com > To: 9fans@9fans.net > Reply-To: 9fans@9fans.net > Date: Thu Apr 23 19:26:06 CET 2009 > Subject: Re: [9fans] 9p2010 > > 2009/4/23 erik quanstrom : > > it occurred to me yesterday morning that the problem with > > a bundle of 9p requests is that 9p then no longer maps directly > > to system calls. > > > > with 9p2000, if you want to do a Tread, it's pretty clear that > > one needs to read(2); traditiona syscalls map directly to 9p. > > true, but it is a one-to-many mapping - for instance, a single call to > open may generate an arbitrary number of 9p messages. > > > not so when bundles/sequences are introduced.  how does a > > user program generate an arbitrary bundle?  can programs > > use bundles at all without being rewritten? > > this is an interesting question. > > as a starting point, i'd envisaged simply changing the existing > system calls to do sequences. > > in inferno, where it's easy to add system calls, it would be > straightforward, i think, to add some additional system-level primitives, > (e.g. readfile) that took advantage of sequencing. > but that is cheating really - ideally you'd want a user-level > interface to this functionality. > > the difficulty with creating the interface is that a 9p call > must be separated into two parts - the sending of the > parameters and the retrieving of the results. > > for a low level 9p interface, i'd imagined something like > the following interface (in pseudo limbo): > > Sequence: adt { > queue: fn(seq: self ref Sequence, m: Tmsg, tag: any); > wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg); > cont: fn(seq: self ref Sequence); > flush: fn(seq: self ref Sequence); > } > > queue adds a new message to the sequence (with an arbitrary > tag to attach to the result of the call). wait waits for the next > reply to come in and returns the tag, the originating tmsg and the > reply. cont continues executing a sequence after it has > been aborted due to error (this will resend tmsgs). flush aborts > the sequence. > > so this is ok when dealing with 9p or the dev interface directly, but > won't work so well > with higher level calls. it would be nice for a user-level program to > be able to string together an arbitrary sequence of system calls > into a sequence, but i'm not sure what a decent interface would look like. > (something like the above Sequence adt, but with a system call description > instead of Tmsg and a system call result instead of Rmsg, perhaps, > although it's not clear what a "system call description" would look like, > or how easy it would be to split system calls) > > the control flow is not straightforward (or perhaps it is - it's the kind > of thing that might just have a nice elegant solution lurking there somewhere). > > something to think about.