On Thu, 11 Aug 2016 11:46:14 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> On Thu, Aug 11, 2016 at 3:05 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Mon, 8 Aug 2016 12:44:06 -0300 Gustavo Sverzut Barbieri
> > <barbi...@gmail.com> said:
> >
> >> On Mon, Aug 8, 2016 at 12:02 PM, Gustavo Sverzut Barbieri
> >> <barbi...@gmail.com> wrote:
> >> > On Mon, Aug 8, 2016 at 11:20 AM, Tom Hacohen <t...@osg.samsung.com>
> >> > wrote:
> >> >> Why do we need a "sent" event? Shouldn't this just be handled by whoever
> >> >> is calling "send" and then check error code or whatever?
> >> >
> >> > That send is asyncrhonous, it will queue and monitor fd for write,
> >> > when select/poll reports that, then it will try to write and report
> >> > back.
> >> >
> >> > Alternatively if we move read to just be notification, then it would
> >> > make sense to make write the same, then it will issue a simple write()
> >> > and no extra infra around that (thus will change to return ssize_t and
> >> > set errno, which can be EAGAIN if socket is non-blocking, or less than
> >> > requested amount if not all data can be written). This would move some
> >> > logic from the core to outside, making developer's lives bit harder
> >> > since they will have to handle memory management for partial writes on
> >> > their own.
> >>
> >> Talking to Tom at IRC, we came with the following approach, which we
> >> both like, others please chime in:
> >>
> >> - Create an EFL interface for FD/Stream operations (ie:
> >> Efl.Interface.Stream): read(), write(), close(), events: read, write,
> >> error... Eventually this can be Efl.Loop_Fd, with extra methods added.
> >> No wrapper around write()/read()... if you set flags to non-block,
> >> then they may return EAGAIN... they may return partial operations
> >> (returns < asked)... they may return errors via errno (or we change
> >> operation to return errno and use an @inout parameter for size_t). If
> >> you set then to block, these operations will block. No internal
> >> buffers or queues.
> >>
> >> - Efl.Net.Socket implements that interface, basically just provides
> >> socket/fd creation. Much simpler! All that is left is manage
> >> socket-specific flags, such as Efl.Net.Socket.Tcp will add some
> >> properties for TCP_CORK, TCP_NODELAY... (then removing the "flags"
> >> bitwise enum in my original proposal)
> >>
> >> - A new class Efl.Buffered_Stream that takes an object implementing
> >> the new interface (ie: Efl.Net.Socket would), and this one would
> >> create the binbuf to handle copies. The purpose is to make easier to
> >> the final user. Language bindings may implement this class on their
> >> own, so they will be able to queue write() queue with reference to
> >> objects using references. This could also come in a different layer,
> >> such as returning a Promise.
> >>
> >> - This approach makes the core cleaner and simpler, it is also
> >> flexible to add different, non-socket fds, such as pipe(2) or read
> >> from a real file.
> >>
> >> If everyone agrees on that proposal, I'll create a new thread with
> >> proposals to enhance Efl.Loop_Fd with new methods, then a reviewed
> >> Efl.Net.* on top of those.
> >
> > i dislike this and still think binbuf (strbuf... ?) are the way to go and
> > extend that a little as needed for some cases like you describe.
>
> the binbuf will be there, but handled elsewhere in a cleaner and more
> generic way:
>
> - any object can implement Reader/Writer/Closer interfaces
>
> - Efl.Net.Tcp, Efl.Net.Unix... Efl.Net.Http.Client... all do
>
> - Efl.File (say something that operates on a real file) also does
>
> - Efl.Buffer (say something that contains and operates on an
> Eina_Binbuf) also does
no no no. i think this is where we are not on the same page.... i am not
saying we should have a SINGLE binbuf... i'm saying the client creates a
binbuf, fills as needed, then HANDS to efl.net. efl.net spools out of it for
writes. efl.net keeps a list of binbufs, not a single one. it owns ALL of them
once you hand it over via api - it takes ownership of the binbuf. :) then there
is no limit on the amount fo buffering that can be done - just keep a linked
list OF binbufs inside.... (well ok max is amount of memory able to be
allocated).
> - Efl.Io.Copier takes two objects, one implementing Reader and the
> other implementing Writer. It will link both and control data
> transfer.
these are a whole different set of interfaces this is growing into... :)
> This allows us to link Efl.Net.Tcp to Efl.Net.Tcp without dynamic
> buffer growing as it would be with binbuf (the Efl.Io.Copier may use a
> pre-defined buffer size to operate, like 4096).
as above... just have a list of binbufs! :)
> The same Efl.Io.Copier may be used to copy two files, or a file to a
> Tcp (upload) or tcp to file (download) and so on.
>
> Whenever we introduce something completely different, like a Pipe, all
> you need to do is to implement Reader/Writer interfaces, Efl.Io.Copier
> will know how to do it for you.
>
> Same for Popen/subprocess (ecore_exe), you can pipe two process (p1 |
> p2), or log to a file (p1 > f1)... or file to process (p1 < f1).
>
> See the following code:
>
> Eo *httpc = eo_add(...HTTP_CLIENT_GET_CLASS, ..address_get("http://e.o";));
> Eo *buf = eo_add(EFL_BUFFER_CLASS);
> Eo *copier = eo_add(EFL_IO_COPIER, ...source_set(httpc),
> ...destination_set(buf), eo_event_callback_add(EFL_IO_EVENT_DONE,
> on_done, ...));
> eo_unref(httpc);
> eo_unref(buf);
>
> ...
> on_done(void *data, const Eo_Event *ev) {
> Eo *o = efl_io_copier_destination_get(ev->object);
> Eina_Binbuf *binbuf = efl_buffer_binbuf_get(o); // or slice_get()
> if we add Eina_Slice
> // operate on binbuffer.... like eina_binbuf_steal()
> }
you're now trying to solve a whole different set of things with this
interface... :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
