[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] mirageos 3.0 : let's break some APIs
Hi,
On Wed, May 18, 2016 at 5:28 PM, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> 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
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` Dave Scott
_______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |