2016-08-10 23:11 GMT+02:00 Gustavo Sverzut Barbieri <[email protected]>:
> ping... since this blocks some stuff I'm doing, will consider in > agreement in 14h. :-) > What I can say is that Eina_Slice is a bad name, should just be Eina_Buffer or Eina_MemBuffer. And I tend to agree with raster to reuse the already available binbuf, if it's feasible. > > On Tue, Aug 9, 2016 at 6:31 PM, Gustavo Sverzut Barbieri > <[email protected]> wrote: > > Hi all, > > > > If you followed the Ecore-Con and Ecore-Con-URL Eoify emails I've sent > > you'll notice one of the proposals is to introduce Stream Reader and > > Writer interfaces, that the default implementations will do a read(2) > > and write(2) with minimum interference. > > > > Those require the traditional "const void *buf, size_t buflen" (read) > > and "void *buf, size_t buflen" (write). You can guess that hinting > > the bindings and users that both are correlated is a pain, thus the > > idea to introduce simple structures to state so: > > > > typedef struct _Eina_Slice { > > const void *mem; > > size_t len; > > } Eina_Slice; > > > > typedef struct _Eina_Rw_Slice { > > void *mem; > > size_t len; > > } Eina_Rw_Slice; > > > > With those Eolian could introduce a new native type "slice" that maps > > to "Eina_Rw_Slice" and "const(slice)" to "Eina_Slice". > > > > These could be introduce in most functions we currently have > > "_length()" variants, like "eina_stringshare_add_length()" could have > > "eina_stringshare_add_slice()". Likewise, APIs could return both in > > one go, like "eina_binbuf_string_get() + eina_binbuf_length_get()" > > could be fulfilled by "eina_binbuf_slice_get()". > > > > For ease of use, we can even pass and return the struct directly, not > > a pointer to one. Example: > > > > Eina_Slice eina_binbuf_slice_get(const Eina_Binbuf *buf) { > > return (Eina_Slice){.mem = buf->buf, .len = buf->len}; > > } > > > > which allows: > > > > Eina_Slice s = eina_binbuf_slice_get(buf); // no malloc/free > > > > Likewise for parameters: > > > > Eina_Error efl_interface_reader_read(Eo *obj, Eina_Rw_Slice dst, > > size_t *used) { > > while (1) { > > ssize_t r = read(pd->fd, dst.mem, dst.len); > > if (r >= 0) { > > *used = r; > > return 0; > > } else if (errno != EINTR) { > > return eina_error_from_errno(errno); /* to be created */ > > } > > } > > } > > > > while allows: > > > > err = efl_interface_reader_read(obj, (Eina_Rw_Slice){.buf = > > localbuf, .len=sizeof(localbuf)}, &used); > > > > (usually that's the expansion of some helper macro, like > read_from_literal()). > > > > > > All of that said, are you okay with adding Eina_Slice and Eina_Rw_Slice? > > > > -- > > Gustavo Sverzut Barbieri > > -------------------------------------- > > Mobile: +55 (16) 99354-9890 > > > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > > ------------------------------------------------------------ > ------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
