oh dear. this new eina_lock thing is a bit of a mess isn't it now?
authorraster <raster@7cbeb6ba-43b4-40fd-8cce-4c39aea84d33>
Sun, 1 May 2011 13:24:08 +0000 (13:24 +0000)
committerraster <raster@7cbeb6ba-43b4-40fd-8cce-4c39aea84d33>
Sun, 1 May 2011 13:24:08 +0000 (13:24 +0000)
commit8e3409cb374f4851df757908877e9c967fe40fd8
tree27fd53f283b0bf9fc973456dd99ff4bdd110a063
parent9fe7159dcfdb8ad545c207b5865e8efa1650f8d9
oh dear. this new eina_lock thing is a bit of a mess isn't it now?
some fundamental errors there. don't go replacing pthread locks with
wrappers unless you know full well what u are doing. havnig threads
only work while "threads are initted" and then init/shtudown the thread
thing every time u spawn a thread.. is pretty silly. what if a thread
ends in the background WHILE u have a lock.. u try unlock.. u know
what ? your unlock DOES nothing. so you retain a lock. next time u
want to lock once a thread is around.. u have a deadlock issue.

even better - the checking if threads are initted and up is not
locked, so it can come up while it is being checked. more race
conditions. u need to clokc the init/shutdown AND lock the checking of
the value... and even then u STILl have problem #1 above. so that code
is now gone.

also trylock trturn inverse logic to the original pthread func and the
macros in evas that used it were not changed accordingly! aaagh!

i've also added backtrace debug ability to eina threads if compiled in
- u can get a bt of who last locked something. i had to do this just to
begin to grasp what on earth was going on. it's off by default.
also... the locks are error check locks to trylock can detect
deadlocks. speacil "2" return for now. better than a poke in the eye
with a sharp stick until we decide what to do. for now i hopew i have
killed this thread lock bug.

git-svn-id: svn+ssh://svn.enlightenment.org/var/svn/e/trunk/eina@59085 7cbeb6ba-43b4-40fd-8cce-4c39aea84d33
src/include/eina_inline_lock_posix.x