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. BR, -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
