On Fri, Aug 5, 2016 at 11:30 AM, Tom Hacohen <t...@osg.samsung.com> wrote:
> On 04/08/16 19:45, Gustavo Sverzut Barbieri wrote:
[...]
>> The blob/binbuf are important optimizations if we care about memory
>> consumption and reducing copies, but they are not mandatory. I'll
>> insist a bit more on them, but if it's the overall agreement to go
>> with buffer copies, then Okay.
>
> I don't see why/how, but maybe I'm missing something, so let me tell you
> what I have in mind, and please correct me if I'm missing anything.
>
> In any networking code you will have:
> char buf[MAX_BUF];
> read(..., buf, ...);
> eo_callback_call(obj, ..., buf, size_of_buf);
>
> Or something similar. Binbuf just means you'll also add it to a binbuf
> and then pass the binbuf instead of buf. So in the most basic case, that
> is one reader of the data (is there any other case??) binbuf is at most
> as good as the example above, and if someone really wants to keep it, he
> just adds it to the binbuf on his own. I don't see how binbuf helps.
- most of time you don read to a stack buffer.
- if there is a protocol where you need a full message to process
(ie: full line up to "\n"), or N bytes specified at the first 4 bytes,
with raw buffer (no storage on the socket side), you can't say "I'm
not taking it, I need more data", you'd need to implement that logic
at your side, or provide something like Qt's "peek()", but that just
work for them because there you need to call "read()" yourself (or
peek()), while in ecore-con like API, we read and deliver to users, so
fd-handler stops triggering read events.
- binbuf provides "remove()" function, then you can easily look into
the buffer up to length (ie: memchr()), if there is no "\n" you simply
keep the binbuf unaltered, that means data was not consumed. If you do
use data, you'd remove it from the binbuf.
** NOTE: ** this is a problem for multiple event handlers, just
one would consume the data, others would not! (Just realized this now)
Alternatively we can change the behavior to not read() ->
callback_call(), just callback_call() and have the user to call a
read() or peek() method. Just be aware that when we read(), the other
event handlers would also have no further data to read, similar
problem as the "NOTE" above.
What do you think?
>> How to do that? Just use constructor { .property_name; } ?
>
> Look at win_type_set in elm.win. The constructor {} directive means a
> function should be used during construction (not necessarily only in
> construction though), and there is another way to say a property is only
> allowed in the constructor. This is done in the C implementation, not
> the .eo declaration though.
by checking the eo_finalized_get(obj)? I found that pattern in
efl_network stuff, using that in my code.
>>> A comment I forgot to make, which is to something cedric mentioned, and
>>> is something that I've said a million times already and I'll say it
>>> again because it's so damn important and people should stop doing it.
>>> Please do not delete objects implicitly. :( Connection is closed? Don't
>>> delete the object, I may steal be dealing with it. Let me eo_unref/del
>>> it if I'm still the rightful owner of the object, it's my
>>> responsibility. Maybe I still want to introspect it before it's gone?
>>> It's my decision to make... If you really think this pattern of
>>> autodeletion is useful, add a helper function people can add as a
>>> callback that just eo_dels an object. It's that simple.
>>
>> Not really, I'm trying to use what is the standard and likely i got it
>> wrongly. I'm okay to add explicit events and methods to close the
>> socket, if that's what I should be doing :-)
>>
>> I just wanted to use socket.close() if people were expecting to do
>> socket.del().
>>
>> Note that this shouldn't mess with refcounts, it's more like
>> evas_object_del() where you want the object to disappear immediately.
>> In this case the socket is not available anymore, so people should
>> stop using that after receiving the event.
>
> Yeah, don't mess with refcounts. Don't delete the object when the
> connection dies.
Added a close() and closed event. Thanks for the clarification.
>>> As for the clarification, I was asked to explain what I meant by
>>> "disagree with the concept". What I meant by that, is a "fatter" wrapper
>>> than thin. I just want a very thin wrapper, and I disagree with anything
>>> that's fatter. :)
>>
>> As per above, I'm trying to have a very thin layer. The blob/binbuf
>> are ways to efficiently use memory in C.
>
> Please explain then, because I don't get it.
The read/consumer part was listed above. As for the producer part,
it's easier to understand:
Most languages, except C, you get reference counted objects that can
provide a buffer interface so you can read the bytes. Then you trade
to keep a list of these objects, use them and then unreference, with
duplicate all their memory in order to wait to dispatch, to then
realloc() as the buffer is consumed until everything is gone and you
free().
Then with bindings, JS, Python and all we could play very nice with
memory by having a way to keep their reference for a while.
If the resource is a backing file we could avoid malloc() for the
actual data by using mmap().
Does it clarify?
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
