Page MenuHomePhabricator

efl.app / efl.loop
Closed, ResolvedPublic

Description

efl_app:

  • Missing api implementation from Efl.Io.Closer
  • arguments event should probebly be here instead of in efl_loop
  • Construction should not be possible from API-land

efl_loop:

  • arguments event should move to efl_app
  • is regular, should probebly be abstract ?
  • there is no need to have message_handler_get beeing @class
  • poll,* events do not tick as fast as they are defined, even if tick is not adjusted.

efl_task:

  • env, env_rest should not be part of efl_task, (when thinking of efl_task is beeing later used as base for spawning other processes), further more, efl_app is only accessable from the main-loop thread which means, other threads cannot manipulate nor read env variables. A more powerfull selfstanding Env object which can be forked or applied to this project might be better and handier here IMO, as it can be passed to later other project constructions.
  • reading and writing to the task is feeling a bit weird, and is not really documented what it is supposed to to, in efl_app this is writing to the console, which is a lot complexer with c#&efl.io.writer, than a simpler Console.PrintLine("asfd")
  • should be abstract
  • run and end should be abstract methods
  • exit code is a int, while we have eina.value in efl_loops begin and end
bu5hm4n created this task.Dec 20 2018, 1:00 PM
bu5hm4n triaged this task as TODO priority.

efl_loop:

  • arguments and quit should indeed be moved to efl_app.eo
  • Not to sure what you mean by poll,*, they only give an hint of the speed of the refresh. They don't define an exact timing, so that they can be throttle when the system needs to save energy.

efl_task is "dangerous" as it allow for execution of any command outside of the sandbox of the bindings. Some bindings may want to be aware of that and I don't know if we are interested to push it at this point for C#.

I understand efl_task more as something to abstract a task into, which can be the process itself, or another process, that is spawned. Having it for something like threads is weird, because it has the command stuff, and env stuff, which is really not part of anything like a thread.

What i would try to do with efl_task is: Abstract env into a seperated object, and only have it as property. Have command only as getter, and either set it like in ecore_init_ex, or don't set it at all, additionally you can also get is as an arry, where you can query the fields / lenght yourself :)

@cedric @zmike @segfaultxavi Does that sound good for you ? I will rev this task here in the revisions i am creating.

Another question, there is no namespace where this is in, which makes sense for c but not IMO for other languages, fine for you to put those classes in Efl.Core ? and eo_prefix: them with efl_ ?

bu5hm4n updated the task description. (Show Details)Dec 25 2018, 3:24 AM

Last update for today: We might want to drop efl.thread and efl.threadio for now, it just SegFaults straight away, caused by the usage of
efl_loop_handler.c. Further more, editing Efl.Task just gets more complicated due to this ...

This may be a dumb question, but why do we need bindings for efl_task? Shouldn't non-C languages have facilities for executing binaries which are better than whatever our bindings would provide? Similar for things like threads: in e.g., rust, why would someone ever use efl's thread bindings?

bu5hm4n added a comment.EditedDec 26 2018, 10:26 AM

First of all, the api is part of the mainloop object, so it needs to be designed in a nice manner anyways.

Furhter more, if we are in the ecosystem of efl, you probebly don't want to exit it if it is not absolutly neccessary. There could be a few reasons why you would have some process inernally started by EFL which is then handed over to the api user, or the other way arround.

And last but not least, for the reasons above, we might want to have it in the future, even if we don't want to have it now, so I would rather look for it now to have it at least not collide with bindings.

@cedric @zmike @segfaultxavi Does that sound good for you ? I will rev this task here in the revisions i am creating.

I don't have a clear understanding of how the current app/task/loop works, or how are you proposing to modify it. Maybe if you point me to a simple example of both approaches... :)

Another question, there is no namespace where this is in, which makes sense for c but not IMO for other languages, fine for you to put those classes in Efl.Core ? and eo_prefix: them with efl_ ?

I don't think it's that bad that Efl.App or Efl.Loop reside in the top level hierarchy since they are pretty important objects. If we put them in a namespace, though, I don't like Core because it does not give much information about what's inside. Maybe Threading or Lifecycle?

In T7514#127518, @zmike wrote:

This may be a dumb question, but why do we need bindings for efl_task? Shouldn't non-C languages have facilities for executing binaries which are better than whatever our bindings would provide? Similar for things like threads: in e.g., rust, why would someone ever use efl's thread bindings?

I have to agree with Mike here. I don't know how hard would it be for the bindings but, as a user, I would expect EFL# to use as much C# infrastructure as possible. If EFL# API requires interchanging objects like Efl.Thread or similar, I would expect them to be silently converted to C#'s equivalent by the binding code.

Regarding this Phab task, what's its relationship with all the tasks you are creating? Shouldn't all of them be children of this one? Or how are you planning to manage them?

I like the Lifecycle namespace proposal from @segfaultxavi as it has more meaning than Core does cary.

As for the thread support in Efl interface, it is currently impossible for any binding to generate anything automatically. There is no information for example about the thread ownership on any of the parameters that goes in and out of this object and so there is no way for a binding to associate it with the right thread runtime information. Also the Efl domain API make little sense in any other language than C and so make it hard for any binding to use it. This are core problem that will take a lot of work to figure out and fix, which is why I am agreeing fully with @bu5hm4n that all the thread related API should be a problem to deal for later and we should keep it beta for the moment. There is enough work to be done.

As for the integration with the native language capability, as I pointed above there are many reason why a binding would decide to not provide the Efl object (security, conflict with existing infrastructure, ...), but having a cleaner interface allow for a custom object created by the binding itself that does allow for integration with the main loop and still use an API that allow integration with the rest of the EFL API. I think that overall make sense as a direction. We should just expect this object to be blacklisted by most binding I would think.

zmike added a comment.Dec 28 2018, 7:25 AM

We should just expect this object to be blacklisted by most binding I would think.

Can we think of any specific language bindings that would use it? Will C# use it?

zmike moved this task from Backlog to Evaluating on the efl: api board.
In T7514#127644, @zmike wrote:

We should just expect this object to be blacklisted by most binding I would think.

Can we think of any specific language bindings that would use it? Will C# use it?

At this point, I don't see how C# or any binding could use Efl.Task.

Mhmm, language bindings do use efl.task based on the fact that they use efl.app which inherits from efl.task ...

Sorry I meant Efl.Thread.

bu5hm4n updated the task description. (Show Details)Feb 20 2019, 11:58 PM

Which leaves us with 1 thing left.

bu5hm4n moved this task from Evaluating to Stabilized on the efl: api board.Feb 21 2019, 10:20 AM
bu5hm4n raised the priority of this task from TODO to Normal.Feb 22 2019, 1:20 AM
zmike closed subtask T7598: efl.task as Resolved.Mon, Mar 11, 10:46 AM
zmike closed subtask T7597: efl.loop as Resolved.
zmike closed subtask T7596: efl.app as Resolved.