some distros 9notably in this case nixos) want to do reproducible
builds. to them this means going around setting mtime for all files to
0. this means efreetd not only thinks mtime is invalid/stupid (0 is
generally just that as midnight on jan 1 1970 is not exactly a
sensible dare for a modified timestamp of a file as no filesystem with
any sanity will have not been modified since that time), but it keeps
mtime at 0 even when things update. this totally breaks efreetd that
expects to find mtime increases over time as things change. it's
necessary because it has to perform a "are mu caches up to date" scan
of all file data it caches and it needs to know if it should rebuild
something based on this.
so this does a few things:
1. it makes mtime have to be an exact match to the cache, not cache
mtime >= file mtime. so any change forward or back is an inavlidation.
2. it now also uses ctime, mode, size, uid, gid, block count and if a
symlink, the sha1 of the symlink path in addition and any change to
these == invalid.
this adds a lot of code and changes how dirs get scanned a bit but it
means it can pick up changes on these 0 mtime distros.
interestingly the policy of mtime being 0 is to have a reprodcible fs
... but ctime still changes and is > 0, as does inode info, so it's
not actually possible to have it totally work... but they try still,
so this is a fix for that problem.
whilst i was doing thisi also noticed efreetd re-red dirs many times
due to icon theme inhritance. i also fixed that to do a LOT less
syscalls by only scanning a dir once as i was rejigging the scanning
code at the time anyway. this should optimize thr scan costs at
efreetd startup too.
@fix
@opt
this previously used an entire eina prefix to determine where to find
efreetd, when a simpler approach would have been to just pass the directory
where it's being installed
this also inhibited running the correct efreetd during in-tree builds and tests,
as it was using the install prefix instead of the in-tree wrapper script
@fix
fix T6713
Differential Revision: https://phab.enlightenment.org/D6516
Summary:
using runtime directory in all cases for this is wrong, as ecore-con has a number
of fallback codepaths for the case where runtime directory is not set or not valid.
by using the same ecore-con function which ecore-ipc uses to generate the socket
string, the error message path should always be the same as the path which is
used by efreetd
extra linkage was required by efreet in order to use ecore-con functions, so
the internal lib variable in the build system was modified to provide this
@fix
fix T7045
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7045
Differential Revision: https://phab.enlightenment.org/D6425
Summary:
some minimal applications, such as test suites, may want to
disable this if they are not in need of any of the
functionality that is provided
@feature
Depends on D5965
Reviewers: cedric, stefan_schmidt
Reviewed By: cedric
Subscribers: stefan_schmidt, cedric
Differential Revision: https://phab.enlightenment.org/D5966
This fixes cycles of init/shutdown/init where ecore event types would
become invalid, since they are now stored in a dynamic array rather than
a statically stored array.
The risk here is that if a module of EFL tends to init/shutdown in a
"normal" scenario then the event type array will grow in a leaking
manner. This could be fixed by resetting those event ID's only when the
loop actually exits (EFL_EVENT_DEL on the main loop). I'm not using
EFL_EVENT_DEL in this patch as this would add too many event callbacks
to the main loop object, which may result in slightly slower event calls
to it, affecting the overall performance.
if efreetd cannot be connected to, stop infinitely trying to spawn it
since this generates crazy cpu load
probably this path should also send some cache events so that watchers
do not simply idle forever
ref T5200
so an odd one. there is a socket, but nothing is actually listening on
it, but clients keep spinning launching efreetd's because the launch,
connect, then get a disconnect and try again immediately keeping
things spinning heavily, so add a delay of 0.5 sec before launchnig
another efreetd if the launch + connect fails and gets a disconnect
within 0.5 sec ... so give up for 0.5 sec before trying again to avoid
a runaway system.
@fix
so efreet mime was loading a bunch of mime type info files, parsing
them on startup and allocating memory to store all this mime info -
globs, mimetype strings and more. all a big waste of memory as its
allocated on the heap per process where its the SAME data files loaded
every time.
so make an efreet mime cache file and a tool to create it from mime
files. mmap this file with all the hashes/strings in it so all that
data is mmaped once in memory and shared between all processes and it
is only paged in on demand - as actually read/needed so if your
process doesnt need to know about mime stuff.. it wont touch it anyway.
this saves about 240-300k or so of memory in my tests. this has not
covered the mime MAGIC files which still consume memory and are on the
heap. this is more complex so it will take more time to come up with a
nice file format for the data that is nicely mmaped etc.
@optimize
this fixes errors like:
ERR<4864>:eet lib/eet/eet_lib.c:645 eet_shutdown() File '/home/osauser/.cache/efreet/icons___efreet_fallback_localhost.localdomain.eet' is still open 1 times !
@fix
i've fixed almost all the eina init/shutdown pairs to do the right
thing now... except one (ecore_shutdown) with comment inline where
eo_shutdown is not called. if this is called we are in crash land.
this needs further inspection.
if you kill efreetd ANd delete all the caches, the restart of efreetd
will lose all icons until an app re-registeres icon extensions and it
can scan all icons .. and then app has to actually get the right
upodate events and do the update properly when this happens. this
fixes that scenario
@fix
this fixes warnings about no efreet dbus session bus in non session
environments as brought up on the mailing lists with:
Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: edje: unset
efreet cache update flag to prevent dbus connections
this moves all of efreetd client and server to ecore ipc, with client
auto-launching efreetd if not found as a service and trying for up to
500ms to connect. efreetd times out on last connection or no
connections after 10sec so it wont hang around forever if not in use.
it seems to work in my testing, so let me know if there is an issue.
@fix
Allow programs to use efreet without requiering a dbus session. This
gives limited functionality, as efreet_icon wont work without a cache.
efreet_desktop will partially work, as it reads info from files directly
if cache is missing.
There's no reason to keep a msg after it was sent. Before this patch we
had edbus_service_signal_send() unref'ing its msg and all the others
not. Also, several users (particularly the edbus_proxy_send() ones) were
forgetting to unref the msg.
This patch makes all these methods unref the message after it has been
succesfully sent:
- edbus_connection_send()
- edbus_object_send()
- edbus_proxy_send()
- edbus_service_signal_send()
SVN revision: 82807
Carsten Haitzler
Boris Faure
Mike Blumenkrantz
Mike Blumenkrantz
Jean-Philippe Andre
Cedric BAIL
Marcel Hollerbach
Sebastian Dransfeld
Sebastian Dransfeld
Lucas De Marchi
Cedric Bail
Gustavo Sverzut Barbieri