Note: It's not a good idea to initialize curl, if you just
want to do some ecore_con network or ipc. Better let them
initialize separatly.
SVN revision: 41743
that still integrate cleanly with the EFL.
ecore_thread_run need two callbacks :
* func_heavy is called from another thread and should not use the
EFL except Eina, but carefully.
* func_end is called when func_heavy is done, but from inside ecore
main loop, so you can at this point call every EFL functions without
fear.
Note :
The system automatically detect how many CPU you have and will spread
the load on all of them.
You must not assume that the result will come in the same order you
requested it. Depend on each CPU load and how heavy the function on it
are.
SVN revision: 41555
The original intention was that if the property is absent or not of extected type (or invalid window) they should return -1, otherwise they should return the number of elements in the property, 0 if none.
Unfortunately they all returned 0 if the property does not exist. Also, ecore_x_window_prop_xid_list_get retuned 0 if the property exists, has no elements, but has wrong type (should be -1).
These issues should be fixed now but this may cause problems in any code that relied on the incorrect behavior.
SVN revision: 41418
To reach this case, have a timer that would not be fired on
_ecore_main_loop_iterate_internal(), for example it's not ready yet
(just_added==1), system would get into this inner loop and would never
stop, since there is timer expired now (next_time == 0.0), if we go to
start_loop it would just get into the same loop, not dispatching and
timers.
Python test 04-idler.py triggered that problem.
SVN revision: 41342
sent by ecore_pipe. The programs based on Ecore on Windows
do not take 100% of the cpu power anymore.
Patch by Lars Munch, modified by me (formatting + guards)
SVN revision: 41179
If there are no other main loop activity than a idlers and one idler
adds a timer, the new (and unique) timer would be ignored since it's
flagged as "just_added" and thus next iteration will not consider it,
possible entering an infinite wait as it could be the only thing to do
in main loop.
Antognolli found this nasty bug while handling timeout-and-die in
Ethumb, where the "disconnect" event is dispatched by EDBus from idler
and it was adding a timer to shutdown the daemon after a while without
clients.
By: Rafael Antognolli <antognolli@profusion.mobi>
SVN revision: 40923