what is happening is that a file gets announced through eio_model
listing code, at this point of time, the monitor does not yet know about
the file. If the file now gets deleted between the annoncing and the
learning of the file from the monitor, then the file got an ADD event,
but no DEL event. Which is a bug.
With this commit there is a new API which asks the monitor if the file
already has the knowledge about the files existance, or not. A few
monitors like win32 inotify or cocoa do not have context about the file
directly, if the OS is now having the same bug, then we are again in
trouble, however, we canot do anything about that. In the case of kevent
or poll, this asks the context of the monitor if the file is already
there.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10006
Summary:
integrate mman.h to make Evil private to the EFL, as mman.h does not exist on Windows. After a discussion with raster, i include sys/mman.h only on non Windows platform.
One issue, though, is that src/modules/emotion/generic/Emotion_Generic_Plugin.h has inlined functions using mmap()
Test Plan: compilation on Windows
Reviewers: cedric, raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9542
eina_promise_data_set is a misleading API and result in conflicted use by
multiple independent piece of code leading to bug and crash. It is also not
necessary and we can avoid using it completely.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D7572
eio seems to consume memory even when not in active use. this saves
most of 270k even when no longer needed. the mempool just keeps stuff
around pretty much forever. also the memory size limit doesn't work at
asll if yous set it to something other than -1. it just locks eio up.
@optimize
so eio_eet didnt free fiels the same as the rest of eio. it thought it
was special. it thought it could just go free() it's objects (even
though they inherit the core Eio_File object type in their structs).
everyone else ended up calling eio_file_free() EXCEPT eio_eet. so the
eio_(long)_file_set() funcs ewnded up adding this eio file to the
tracking list via eio_file_register() but never unregistered because
they really liked to just do their own thing anyway...
BAD CEDRIC! SPANKING TIME
http://33.media.tumblr.com/3422c76c33c3b9b045f623ff73e0bf8d/tumblr_mhvu61N9br1rbavngo1_500.gi
so this unifies all allocation to now use a single allocator (that
also ensures all eio async io objects are zero'd out), and a SINGLE
free path, and then it all works. no more valgrind complaints on e
shutdown/restart whilst eio "things" were used before or ... maybe
still around.
this should fix T2129
so try again "git master" after this commit.
@fix
This should avoid potential crash during shutdown while some Eio thread
were still running. We are still not blocking for more than 30s, so if
an IO is blocked on a dead device, you should be fine.
When using eio_file_stat_ls() (or any other exposing Eio_File *handler),
it will not be possible to use it from the main callback due to eio
freeing data too fast from the thread.
Moved frees from _eio_file_eina_ls_heavy() to eio_async_end() to be
sure that all the calls to main callback are over.
This implied adding the Eina_Iterator from eina_file_stat_ls to
the _Eio_File_Ls structure.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
some functions were being checked but their IFDEF not being handled,
others (getpwnam and getgrnam) were isolated in a code that is now
Windows, then no need to check them as well as these are POSIX.
SVN revision: 81934