I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
As reported by vtorri, sometimes ecore_exe on win32 will encounter double
free issues. This was because the variable was freed, but not set to NULL
as expected by the cleanup function.
Fixes T2675
@fix
This fixes the CPU to be usedat 100% for each thread in ecore_exe. This
is obviously not an ideal fix and will be improved in the future.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Output and error threads could not read all the data sent by the child.
Based on a patch by Guillaume Friloux
@fix
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The correct way of disposing of an object in a failed finalisation is to
return NULL, not to delete it.
Also, since the destructor is already called when the object is deleted
anyway, there's no point in having cleanup code in the finalizer too.
@fix
CreateProcess() has a flags parameter which is being passed
"run_pri | CREATE_SUSPENDED".
The issue lies in the value of run_pri. It is best explained by the
following code somewhere else in the file:
switch (run_pri)
{
case IDLE_PRIORITY_CLASS:
return ECORE_EXE_WIN32_PRIORITY_IDLE;
The run_pri variable is supposed to store a value from the win32 API while
it was used to store one from the ecore API.
If I recall correctly, the windows one is equal to 32 and the ecore one to
9999. Meaning 9999 ended up used as flags so let's have a look at what that
actually enabled; the reference is "Process Creation Flags" from MSDN
http://msdn.microsoft.com/en-us/library/ms684863%28v=vs.85%29.aspx .
9999 gives 0x0000270F and this matches
DEBUG_PROCESS | DETACHED_PROCESS | DEBUG_ONLY_THIS_PROCESS
| CREATE_SUSPENDED | CREATE_NEW_PROCESS_GROUP | CREATE_SEPARATE_WOW_VDM
| CREATE_UNICODE_ENVIRONMENT | <0x00002000 matches nothing>
Matches nothing? Weird. Well, maybe. Except that I stumbled upon this define
in the mingw-w64 headers:
#define CREATE_FORCEDOS 0x2000
Mingw-w64 only has a #define, Wine has nothing (they don't do DOS anyway),
but ReactOS has some code about it:
https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/kernel32/client/proc.c;hb=f60941f8dc775427af04eb0a3c3e4d38160c7641#l3007
Overall the actual set of flags probably made very little sense and wasn't
working very well. :)
I also noticed the following in the mingw-w64 headers:
#define INHERIT_CALLER_PRIORITY 0x20000
This should be a better match for what seemed to be the original intent of
inheriting the priority. I haven't tested it and it's only documented on
MSDN for Windows CE and similar so I'm really not sure about what it does.
MSDN however mentions that the child processes will have at most the
"normal" priority by default (same as its parent if the parent has less
than the default one) but I'm under the impression a process can raise its
own priority level... Anyway, "NORMAL_PRIORITY_CLASS" will do for now.
With this change and a couple others, elementary's theme builds properly
on Windows (_on_ Windows). I'll assess the usefulness of the other changes
in my tree over the next few days.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This is the first step towards splitting it nicely. This fixes
compilation on windows (or so it seems from my testing) and takes out
all the platform specific code (posix included) out of the main source
file.
This should fix the dumb way it was split until now (everything was redundant).
Now we just reimplement the parts we need to reimplement and the rest is shared.
The win32 code is called from within the normal code.
Tom Hacohen
Vincent Torri
ChunEon Park
Vincent Torri
Vincent Torri
Andrii Kroitor
Adrien Nader
Vincent Torri
Carsten Haitzler