setenv and unsetenv are not portable. i explained to you at fosdem
there are issues and it's why i used putenv in the original
implementation and even though it's a pain (the string tou pass to
putenv is a pointer used literallt from there on in and you get it
from getenv, thus making ownership a pain -this is a libc issue we
can't readily solve). use putenv like the original code. then put it
back in. vtorri now has windows porting issues with the setenv use. i
knew there was a reason that still existed...
in addition your in_sync stuff is broken. psuedocode:
// assuming BLAGH env is not set to anything here
c = efl_core_env_get(global_env, "BLAH");
...
putenv("BLAH=10");
...
c = efl_core_env_Get(global_env, "BLAH");
i will get NULL in both cases for c ... but i should get "10" for the
2nd in reality. reality is lots of code across application code and
libraries will at times mess with the environment. it has to work with
this. the prior implementation did work with this.
Revert "ecore: here comes a env object"
This reverts commit 2373d5db5b.
Revert "efl_task: remove env from this object"
This reverts commit c3d69f66a6.
Revert "ecore: get rid of commands in efl_task."
This reverts commit 616381e9cf.
Revert "ecore: here comes a command line object"
This reverts commit 48e5684b3c.
1. this is broken:
EOLIAN static const char*
_efl_core_command_line_command_get(const Eo *obj EINA_UNUSED, Efl_Core_Command_Line_Data *pd)
{
return eina_strdup(pd->string_command);
}
it returns a const char * BUT it duplicates it on return. no. a big
fat honking NO. return a char * or don't duplicate. pick.
2. _efl_core_command_line_command_array_set() is broken by design. it
accepts an array of strings, but the strings are owned by the caller
who creates the array (requiring they free them up themselves after
this call) but the array becomes owned by the callee. the code here frees the
incoming array but doesn't care about the string content of it. it's
leak heaven waiting to happen (or bugs when someone wants to access
the array they create to walk it to free the strings they put into it
after it is set).
i brought this up and it was dismissed. now exactly he issue i brought
up is there with mixed ownership and the added complexity as well as
transfer of some ownership but not others.
go back and think about this so it isn't broken by design.
Note that the usage in efl_thread.c should and could be removed.
the problem with its usage is that when the ARGUMENTS event is fired,
noone ever had the chance to subscribe to the loop of the thread yet. So
all in all this is unneccessary, since noone could ever touch that.
Differential Revision: https://phab.enlightenment.org/D7517
Summary:
this makes efl_task abstract which ensures that it cannot be
instanciated. Further more, functions that needs to be implement are now
pure_virtual.
ref T7514
Reviewers: zmike, segfaultxavi, cedric
Reviewed By: segfaultxavi, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7514
Differential Revision: https://phab.enlightenment.org/D7508
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.
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
this is astart of the work for having a common task class/interface
between loops, threads ane exe's so the i/o is all symmetric and works
the same way between all of them as well as similarly for launching
and knowing when the exit etc. etc.
this is not final and not perfect, but it's a start. comments of
course welcome
Marcel Hollerbach
Carsten Haitzler
Daniel Kolesa