On 05/11/13 00:21, Cedric BAIL wrote:
> Hello,
>
> On Mon, Nov 4, 2013 at 11:00 PM, Tom Hacohen <tom.haco...@samsung.com> wrote:
>> As you may have noticed, Cedric committed Ecore Coroutine a while back.
>> I don't know why we need our coroutine implementation, and I don't think
>> anyone uses or will ever use it. Those aside, the current coroutine
>> implementation only works on Linux and relies on very hackish
>> implementation details (which means it won't work on old glibc versions
>> and possibly new glibc versions as well). I don't understand why we let
>> that in, and I think it should be removed from Ecore asap, especially
>> before the release.
>
> Care to provide a link about it being broken on older and newer glibc
> ? It is still part of POSIX, just marked deprecated. As for usefulness
> it make it possible to reschedule a piece of code as you receive
> packet in without the need to use callback. Some library that have a
> really bad design and we can't find alternative do need this kind of
> infra if you want to run them in sync with our main loop.
/* The idea of this trick come from libcoroutine */
/* __jmpbuf[6] == stack pointer */
/* __jmpbuf[7] == program counter */
coro->context->env[0].__jmpbuf[6] = ((uintptr_t)(&coro->stack));
coro->context->env[0].__jmpbuf[7] =
((uintptr_t)_ecore_coroutine_entry_point);
This is not portable. I've used this before at uni and the thing failed
miserably on old systems. Also, as you can see from it, it's not really
clean and can break at any time...
>
>> An example of already existing pain regarding it:
>> https://phab.enlightenment.org/T456
>
> This is a problem in configure.ac not in the code. MacOS X has
> ucontext, for an unknow reason configure doesn't detect it.
>
>> I don't see why we need to make our lives harder (porting) with
>> including something so hacky that is not even that useful to us.
>
> Removing it is still an option. You will have noticed that the code is
> ported to windows and unix, with even a fallback for system that don't
> fall into those two categorie... So the problem is not portability of
> the code, but to have configure.ac detect things correctly.
>
I understand that it *could* be used. But it's not. We should not just
add more random code that no-one uses in, "just in case".
What are your thoughts?
--
Tom.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
