(sorry I hit send too soon!) On Sun, Jun 5, 2016 at 2:45 PM, David Scott <[email protected]> wrote:
> Hi, > > On Wed, May 18, 2016 at 5:28 PM, Mindy <[email protected]> wrote: > > ... >> >> I'm surely missing many things folks would want to incorporate in a big >> API-breaking release -- please do let us know what they are. :) >> > > I'd like to address some problems with `FLOW`, in particular: > > - the `read` function > > val read: flow -> [`Ok of buffer | `Eof | `Error of error ] io > > returns a fresh arbitrarily-sized buffer, which is inconvenient when > unmarshalling data of known size. For example in ocaml-9p > https://github.com/mirage/ocaml-9p/blob/cb9f5a6c83051ac5dfa7fc7a43ca6a2910a0a241/unix/flow_lwt_unix.ml#L50 > we constantly allocate buffers of size 1k and read as many bytes as are > available, even though at the higher-level the messages are preceded by > fixed-size headers containing payload lengths. It would be better if the 9P > client could have a single per-connection read and write buffer with length > set to the dynamically-negotiated message size and then use a new function > > val read_info: flow -> buffer -> [ `Ok of unit | `Eof | `Error of error ] > io > > This would make `FLOW` more similar to `BLOCK` > and a second problem I have with `FLOW` :) is over close. `close` is defined as performing a flush and signalling that no more writes will happen, like `Unix.shutdown`. I think this is fine, and it matches what the TCP/IP stack is doing. I think we're missing a `disconnect` which would get rid of all connection state, like `Unix.close`. In other places we have `disconnect` by virtue of `include DEVICE`. I think we should add the missing `disconnect`. Anyway, sorry for 2 emails where 1 would have done, let me know what you think! Cheers, Dave
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
