This is a part of T5301 (major interface rework for EO).
Ecore mainloop needs to be a proper efl object so multiple loops can exist in multiple threads and can interact with each-other, message/call back and forth etc.
- Efl.Loop needs to exist
- EFl.Loop neds to not rely on globals so multiple instances can be created
- Cleanup ecore poller for EO (no cb function): T5524
- Cleanup ecore_types.eot
- Fd handlers (Efl.Loop.Handler)
- Ecore Event stream (Efl.Loop.Message + Efl.Loop.Message.Handler)
- Rename ecore_main_loop_get() to efl namespace
- Efl.Loop events for signals
- USR (1 & 2)
- Efl.Task common interface for running executeables and new threads
Executables and Threads should be similar so it is easy to move work from executables to threads and back depending on what would be best. Having at least one form of consistent I/O that works between threads and processes (like stdin/out or specialized pipe fd's). Also pause/unpause as well as priority/scheduling controls.
- Ecore Exe -> Efl.Exe (use Efl.Task)
Need an Eo API for launching Exe's and controlling them and knowing when they exit etc. (what Ecore_Exe stuff did).
- Ecore thread creation/destruction plus per thread loop creation + execution (Efl.Task used)
The idea is one Efl.Loop per thread, with a local Eo object representing the spawned thread on the other end so you can use this object and methods on it to listen to events from the other loop, send things to it or even control it.
- Efl/Eo/Efl.Task version of ecore_main_loop_thread_safe_call_sync/async();
- Probably a method on the Efl.Task iface to call a func ptr + void ptr + sync & async versions
- Per-loop/executable process I/O to/from parent process or parent "loop" (interface for this)
- Efl.Something interface for handling writes/sends and events for returning data coming back
- Inherit this interface in Efl.Task and Efl.Loop
- For exe's a flag to re-use stdio or special fd's
- Probably have option for line based parsing due to common usage for stdio
- Threads can have special I/O channel for void ptrs + free funcs and/or shared objects
- Clean up signal to event conversion code
- Dedicate a thread that blocks all signals, uses sigwaitinfo() + pipe back to main loop
- Efl.Loop events for power, battery and other lifecycle events (pause, resume, etc.)
- System Time/date change
- Hostname change
- Locale/region change
- Low memory
- Charging status change
- Low battery
- On battery power (or not i.e. AC)
I/O from main loop to parent process by default would be stdio/stream based using stdio, unless launched with specific environment vars then special fd's would be inherited from a fork other than stdio and go to parent process as a side-channel available to efl apps. Needs loop methods to write such data and events to deliver input. Also Efl.Task for the other side too. The same I/O methods would come from the Efl.Task interface and be usable between threads (parent/child thread - this isn't strictly correct but an idea we need to introduce). Try and make threads and exe's as consistent as possible this way. Efl.Task would define environment vars, commandline and/or argument array, same events for exit of thread/process and consistent exit code mechanism. Threads can have also the ability to send void ptrs or shareable objects around.
Efl.Net style Elf.Io.* reader/writer etc. interfaces seem far too complex for something that should be a lot simpler.