],
[want_g_main_loop="no"])
-# thread safety
-
-AC_ARG_ENABLE([thread-safety],
- [AC_HELP_STRING([--enable-thread-safety],
- [enable thread safety. @<:@default=disabled@:>@])],
- [
- if test "x${enableval}" = "xyes" ; then
- want_thread_safety="yes"
- else
- want_thread_safety="no"
- fi
- ],
- [want_thread_safety="no"])
-
# epoll
AC_ARG_ENABLE([epoll],
want_glib="yes"
fi
-if test "x${want_thread_safety}" = "xyes" ; then
- AC_DEFINE([HAVE_THREAD_SAFETY], [1], [Define to enable thread safety])
-fi
-
want_ecore_timer_dump="no"
if test "x${build_profile}" = "xdebug" && test "x${ac_cv_func_backtrace}" = "xyes"; then
want_ecore_timer_dump="yes"
echo
echo "Ecore:"
-echo " Thread safety..............: $want_thread_safety"
echo " GLib support...............: $with_glib"
echo " Use g_main_loop............: $want_g_main_loop"
echo " Gathering memory statistic.: $ac_cv_func_mallinfo"
_ecore_lock(void)
{
#ifdef HAVE_THREAD_SAFETY
+ /* THIS IS BROKEN AND NEEDS FIXING
+ *
+ * the concept of lock to execute main-loop related functions is okay
+ * and the code below is correct per se, but with its usage in Ecore
+ * is leading to hard locks that must be investigated.
+ *
+ * One failure possibility is missing _ecore_unlock() that leaves
+ * the lock taken and on next take it will block.
+ *
+ * Another failure possibility is one function that takes the lock
+ * and calls some API function that also takes the lock, leading to
+ * block.
+ *
+ * When these are fixed, remove the HAVE_THREAD_SAFETY and leave it
+ * always on. To eliminate the lock overhead for non-threaded
+ * applications, have a global boolean that is set to TRUE by user
+ * if he uses this features, much like eina_log_threads_enable().
+ * -- Gustavo, December 6th 2012.
+ */
eina_lock_take(&_ecore_main_loop_lock);
#else
/* at least check we're not being called from a thread */