On Sat, Jan 14, 2012 at 11:38 PM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote:
> On Sun, Jan 15, 2012 at 2:19 AM, Michael Blumenkrantz > <michael.blumenkra...@gmail.com> wrote: > > On Sat, 14 Jan 2012 23:15:37 -0500 > > Youness Alaoui <kakar...@kakaroto.homelinux.net> wrote: > > > >> Hi, > >> > >> I've just updated my EFL build for the PS3 and it was broken. eina_init > >> isn't working anymore because eina_value doesn't init itself correctly. > The > >> issue is that if it's unable to iitialize a lock, it will fail the init > >> which fails eina_init (and ecore_init, etc..) > >> The problem is that on the PS3, there is no pthread library so threads > are > >> disabled on eina and eina_lock uses eina_inline_lock_void.x which just > >> returns FALSE/FAIL for every API call. This also causes another issue > with > >> evas which slows it down because it tries a eina_lock_take_try (which > >> fails) and forces it to wait a bit before doing anything then it spams > my > >> terminal with warnings about not being able to get a lock. > >> I would suggest to change the behavior of eina_lock (on 'void' > platforms, > >> which do not support locks) to always return TRUE/SUCCEED so it doesn't > >> break everything below it. > >> > >> What do you think ? > >> > >> Thanks, > >> KaKaRoTo > > unfortunately this would be an api break since eina_lock was present in > the 1.1 > > release... > > actually a bug, then it must be fixed. > @Michael That's true, it was in 1.1 release, but it wouldn't be an API break, rather a behavior change (does that count as api break?) But yes, it should be thought of careful, that's why I wrote the mail. The thing is that a eina_lock on a system that does not support threads is basically an undefined behavior (and as far as I know, it is not documented how it would react in such a case). How many systems do you have/support which make use of the eina_lock_void (compiled without threads support) ? Also, I'd actually think that this is the right behavior.. if you do eina_lock_take on a system without threads, then it shouldn't "fail" as if the other thread is still holding the lock.. it should tell you "yes, you can continue safely", so it should return TRUE. @Gustavo: yes it's a bug because right now, this configuration will not be able to initialize anything. What did you mean by #ifdef if ? you mean only do the lock init if threads are enabled ? That might fix the current bug of eina_init failing, but it wouldn't fix the eina_lock_take_try issues I discussed. For now, locally, I made eina_lock return TRUE on the ps3, so I'm not stuck, but I'd like to have this properly fixed, hopefully without any hacks. Thanks > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
