This is an interesting one. I was wondering if it didn't impact our performance, but nop. That is another problem.

In D8336#152653, @bu5hm4n wrote:

Okay, if i am now using the most upperst revision then the items do not get mixed up anymore. However, the first population run finishes before the new path is populated. This is something that I would not expect as a user.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

Rebase.

In D8335#152309, @bu5hm4n wrote:

_eio_build_st is protecting itself from doing what I wrote above, it just feels a little bit fragile, since changing this would leave the world in parts, maybe make pd->st = NULL and pd->info = NULL; in case of an error ?

Seems to remove only what it says it was removing. Good to land.

Rebase and correct.

Rebase and correct.

Rebase and correct.

Rebase and correct.

Rebase and correct.

Rebase and correct.

Rebase.

Rebase.

Rebase and correct.

Rebase.

Rebase.

Rebase and correct.

Rebase and correct.

I think you are right. It seems that for legacy we should be able to apply text before finalize. Going to be fun! Will adjust patch to be only for invalidating and after.

Main reasoning is that someone that is looking on how to return an Eina_Value from an Eina_Future would find this function very quickly and wouldn't have to understand much of what it does to use it.

I would think that the main misleading things is that the returned Eina_Value is of type EINA_VALUE_TYPE_PROMISE and that there is no EINA_VALUE_TYPE_PROMISE. That might require more documentation. Otherwise I feel the name does match what the function does, it takes an Eina_Future and return an Eina_Value.

How did that ever work???

In D8334#151205, @segfaultxavi wrote:

First off, thank you both for giving my brain the opportunity to hurt so much.

In D8375#151127, @zmike wrote:

I tested this series locally and it still doesn't fix the fileselector unit test deadlocks. Also there's still quite a few errors.

Hum, there is a side effect to being passed by values vs references. In one case events can not alter the value as it pass there handler. In the other, they can. Maybe we should have a "const" marker to specify explicitly this intent. I think this also make a stronger case to mark efl_event_callback_call a protected function and generate function that will have the proper type checking in their prototype.

D8358 is actually fixing the issue by enforcing efl_unref to actually execture the auto unref logic. I didn't make efl_isa and all the other direct call to eo.c function enforce the auto unref, but maybe I should. My logic was that it would be necessary to always use efl_ref/unref to do something with a part with those function, but maybe that is incorrect. I don't know why someone would do :

efl_isa(efl_part(obj, part), SOME_CLASS)

But I guess it should work. Maybe you can add a patch that does the samething as D8358, but for efl_isa?

In D8359#150949, @bu5hm4n wrote:

Tbh. i am confused *when* its legal and *when* its not. Because right now, this function is always executed at a time where the layout object is *not* finalized. (Check _efl_ui_progressbar_efl_ui_widget_theme_apply for example) So this would break that right now AFAICS.

In D8359#150945, @bu5hm4n wrote:

I am nearly 100% sure that this breaks behavior. We use elm_layout_text_set before finalize is called, but the theme is maybe already set, so we want to call elm_layout_text_set on it...

In D8372#150939, @bu5hm4n wrote:

The macro ensures that the test case fails when there is a ERR.

In D8335#150883, @bu5hm4n wrote:

This commit does a little bit more than it describes. It also makes all the properties "direct_info", "mtime", "atime", "ctime", "is_dir", "is_lnk", "size", "stat" accessable. So as long as they have a value, this value is returned. Which also means when _eio_build_st is called twice, and the first one succeeds, and the second does not. Then the old value is returned i think ? All in all, should we make pd->st = NULL and pd->info = NULL; in case of an error ?

Hum, this test should really not generate error. Like if it print a message, there is a problem that need fixing. I am not sure what the point of those macro would be in this context.

Forgot to say, but change where made as requested.

In D8334#150922, @bu5hm4n wrote:

We might want to consider renaming eina_future_as_value to something that does *not* suggest that the eina_value is a future :D

In D8372#150912, @bu5hm4n wrote:

I was more talking about adding DISABLE_ABORT_ON_CRITICAL_START; DISABLE_ABORT_ON_CRITICAL_END; to the test, so we ensure this test is not starting to print error messages.

In D8372#150889, @bu5hm4n wrote:

Well, this is a nice test. However, could we check that this prints no error ? :)