Peter Wehrfritz wrote:
> Peter Wehrfritz schrieb:
>> Sebastian Dransfeld schrieb:
>>> Peter Wehrfritz wrote:
>>>> Hi all,
>>>> I took Vincent's last ecore_pipe approach and changed ecore_pipe_write
>>>> to accept variable long data and not only a pointer. I also added the
>>>> possibility to pass a data pointer to the handler callback to avoid the
>>>> usage of globals. The win version does probably not work.
>>>> Please read it carefully, because I'm not very familiar with pipes.
>>>> Attached you'll find a little test app, too.
>>> Shouldn't you check that you actually read the number of bytes the
>>> system says is in the pipeline
>> Right, sorry I forgot to mention, that I skipped them, because I'm not
>> sure how I should handle these cases. Of course that doesn't mean that
>> we have not to handle them.
>> 1. What shall we do if the return size is smaller (but > 0). If I
>> understood it right, that can happen if the writing process writes more
>> bytes then PIPE_BUF. Should we then retry it, to get the rest of the
>> data. Or should we buffer the already read data and try it to get the
>> rest when _ecore_pipe_read is called again.
Buffering is simplest and easiest. Checking ecore main loop already
checks for available data and calls the read function, so why duplicate
>> 2. What should we do if we get an error messages? And when can this
>> happen? If we can loose some bytes then we are out of sync with the
>> lenght and data portions and the results would be randomly, but in any
>> case wrong.
Close the pipe on error and signal the sender. As you say, any error
will make the pipe out of sync and void. The sender can then
re-establish the pipe and resend.
>> 3. In Vincent's version he called read as long as he gets pointer from
>> the pipe, should I also loop as long as there is data in the pipe?
Loop as long as there is data, but add a time limit. In ecore_con_url
there is a limit on animator frametime.
/* make this not more than a frametime to keep interactivity high */
if ((ecore_time_get() - start) > ecore_animator_frametime_get())
>> I hope I covered here all possible errors.
> Can anyone help here? I don't need it personally, but it'd be nice to
> have it in ecore. Especially since it isn't that trivial like it looks
> on the first sight.