this will crash due to invalid memory access if an event is triggered after
the sentry is destroyed
Differential Revision: https://phab.enlightenment.org/D6845
it seems that this should have been a pop call, not the function
pointer. This key eina_array_pop is never used. Nor would the array get
smaller, so i assume this should be a pop call.
Differential Revision: https://phab.enlightenment.org/D6814
Summary:
Trying to delete a file from a creation notification callback can
fail. Sometimes the eio model test would sit forever in select()
waiting for events that will never occur because of this.
This happens since d84a268a71 broke
deleting of files that haven't yet been assigned a type. Before
this commit a delete_me flag would be set before attempting to
build a stat buf asynchronously, and then on completion the file
would be deleted.
I think this was changed because that could potentially race with
other async calls and delete the file sooner than expected. So
instead of reverting I've made a special delete path that shouldn't
race with non-delete paths.
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6543
emitting events if the delete_me flag is set may result in events being emitted
for an already-freed monitor, resulting in both invalid memory access and a
deadlock later on if eio_shutdown has been called at this point
this causes the monitoring thread to check the status of the backend during the
block where the main loop and thread are in sync, avoiding any data races which
could occur when checking the flag at another time, and also avoiding accessing
the internals of the Ecore_Thread which could also have been deallocated during
shutdown
fix T7086
Differential Revision: https://phab.enlightenment.org/D6449
the fallback method of calling stat() on the monitored paths does not allow
for various eio events to be emitted, meaning that any application which relies
on those events can never receive them
this provides a method for checking a monitor to determine which functionality
is available, and also provides more explicit documentation regarding events
that are not provided by fallback monitoring
this method is marked as beta
@feature
Differential Revision: https://phab.enlightenment.org/D6447
for some reason, the fallback thread would exit -> create timer ->
create idler -> create thread; the existence of the idler makes little
sense and introduces variability in the timer interval
@fix
Differential Revision: https://phab.enlightenment.org/D6441
threads should not be waited on here during shutdown since these same
threads may be waiting on the main loop anyway
instead, perform as much deallocation as possible,
mark the monitor as deleted, and then set the thread to canceled and
allow the thread to clean itself up during its cancel/end callback
@fix
Differential Revision: https://phab.enlightenment.org/D6440
Summary:
the default value for the fallback poll monitor timer interval is 60.0 seconds,
which is not useful for all cases, such as CI, where we don't care about cpu
usage and just want things to process as fast as possible at all times
this enables setting the interval to any value, ensuring that any existing
timers are modified to use that value immediately
@feature
Reviewers: stefan_schmidt, bu5hm4n, raster, devilhorns, ManMower
Reviewed By: bu5hm4n, ManMower
Subscribers: ManMower, raster, bu5hm4n, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6247
Summary: S_ISSOCK does not exist because sockets do not exist
Reviewers: vtorri, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D6035
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
This reverts commit 135154303b.
Revert "efl: move signal events from efl.loop to efl.app"
This reverts commit 3dbca39f98.
Revert "efl: add test suite for efl_app"
This reverts commit 3e94be5d73.
Revert "efl: create Efl.App class, the parent of Efl.Loop"
This reverts commit 28fe00b94e.
Go back to before efl.app because I think this should be done with
superclassing here not a parent object. reasons?
1. multiple loops per single thread make no sense. so if multilpe loop
objects they wont be contained in a single app object and then deleted
like this.
2. the app object is not really sharable in this design so it cant be
accessed from other threads
3. it makes it harder to get the main loop or app object (well 2 func
calls one calling the other and more typing. it is longer to type and
more work where it is not necessary, and again it can't work from
other threads unless we go duplicating efl.app per thread and then
what is the point of splittyign out the signal events from efl.loop
then?)
etc.
After a function pointer validation branch got enabled, it turned
out that people have been writing obviously incorrect eo files
all along.
So while I have no idea if this is logically fully correct, at
least EFL builds again now...
cc @thiepha
Mike Blumenkrantz
Marcel Hollerbach
Derek Foreman
Larry Lira
Cedric BAIL
Daniel Kolesa
Mike Blumenkrantz
Xavi Artigas
Daniel Kolesa
Carsten Haitzler
Al Poole
Vincent Torri