On Sun, Jan 15, 2012 at 8:56 AM, Youness Alaoui <kakar...@kakaroto.homelinux.net> wrote: > The PS3 OS's system call for threads/mutex/cond/sem is almost the same as > pthread, so it shouldn't be very compilcated.. I already ported > pthread-embeded to the ps3 but I don't like their implementation (and it > causes some issues with the newlib headers used by the toolchain. > I will think about it though, it might be easier to just write ps3 specific > code for it in eina. But it wouldn't help porting efforts of other non-efl > applications to the PS3 that depend on pthread.
who cares ? :p Vincent > > On Sun, Jan 15, 2012 at 2:47 AM, Vincent Torri <vincent.to...@gmail.com>wrote: > >> On Sun, Jan 15, 2012 at 8:40 AM, Youness Alaoui >> <kakar...@kakaroto.homelinux.net> wrote: >> > Yes I could, but I don't really see the point to be honest, I think >> porting >> > pthreads would be much more convenient rather than porting every library >> > that uses pthread into using the ps3 specific API. I just lack >> > time/motivation to do it, but it should be pretty straighforward... >> >> well, porting pthread to a system == being POSIX compliant (wrt >> threads) so it's not so simple. I saw the code of pthread-win32 and >> it's an horror (because of that). Just locking a mutex is complicated >> and in fine uses the win32 API. So i decided to use native win32 API. >> One call and that's all, it's faster than pthread-win32 and it >> consumes less memory. >> >> Vincent >> >> > >> > On Sun, Jan 15, 2012 at 2:27 AM, Vincent Torri <vincent.to...@gmail.com >> >wrote: >> > >> >> On Sun, Jan 15, 2012 at 8:06 AM, Youness Alaoui >> >> <kakar...@kakaroto.homelinux.net> wrote: >> >> > On Sun, Jan 15, 2012 at 1:52 AM, David Seikel <onef...@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. >> >> >> >> >> >> I'm wondering how come a hyperthreaded CPU with a dozen extra >> >> >> specialized cores has no thread support? It might not have pthread, >> >> >> but it might have some other sort of thread support that could be >> used >> >> >> instead? >> >> >> >> >> > Yes it has threads support, and the official SDK (Which we can't >> legally >> >> > use) has pthread, but we don't have an open source port of pthread to >> >> their >> >> > own system calls. So for now I'm working with it without threading >> >> support. >> >> > I will eventually (some day) port pthread to it then all of this will >> go >> >> > away, in the meantime, I prefer to concentrate on other things (it >> also >> >> > helped me find a few bugs in the EFL for when it gets compiled without >> >> > threads) >> >> >> >> if there's thread support, you can try to use the native one, like i >> >> did for Windows, right ? >> >> >> >> Vincent >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> 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 >> >> >> ------------------------------------------------------------------------------ >> 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 ------------------------------------------------------------------------------ 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
