On Tue, Nov 5, 2013 at 7:04 PM, Tom Hacohen <[email protected]> wrote: > On 05/11/13 00:21, Cedric BAIL wrote: >> On Mon, Nov 4, 2013 at 11:00 PM, Tom Hacohen <[email protected]> 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...
Old libc are not supported on 1.8. Also as stated before, this code is not to be used on most system at all, that's for the system who are not Posix and not Windows. It is there for people that are porting EFL to a weird platform and want a starting point. >>> 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". I started using it for integrating libssh. It does the job. I just gave up on libssh and friend as they are just to much a pain to deal with, better rewrite our own ssh library there in fact. > What are your thoughts? Already removed if you did follow git commit. Now I did not remove it for portability reason (people waking up the day of a release because MacOS X is broken will have to live with it, if you want support for your platform, care about it ! That code is more than 6 months old, so nobody did care about MacOS X in that time lapse...), but because I don't need it and I think nobody does at the moment. -- Cedric BAIL ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
