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
The old way we could run endless with the following case:
int my_buggy_idler(void *data) {
ecore_idler_add(my_buggy_idler, NULL);
return 0;
}
since it would append to that list, then the list would never end.
Now we just dispatch up to the last know idler, then go back to
regular processing, if nothing happens we'll be back to dispatch
again.
I tested it here and works fine, but might show issues with ecore
enterers/exiters of some applications that rely on the old (broken)
behavior.
SVN revision: 40847
hence we must use closesocket() to close a socket instead of
close(). In addition, we should improve the closing of the
socket (see http://tangentsoft.net/wskfaq/newbie.html#howclose)
* use PIPE_FD_INVALID for invalid fd / socket
* use PIPE_FD_ERROR for invalid result when sending / receiving
data on fd / sockets
next step is to manage correctly errno on Windows with WSAGetLastError()
(see http://tangentsoft.net/wskfaq/articles/bsd-compatibility.html)
SVN revision: 40846