Re: Project Leviathan - wxEuphoria 3.1.0 alpha1
- Posted by petelomax Jan 16, 2017
- 1809 views
I'm still trying to understand is how there is a "wrong" free() and a "right" free().
I tried to write an answer to that, and struggled. 
But I think I finally got there.
Don't the process and its loaded libraries share a common heap?
Erm, usually, but there is also HeapCreate to consider... You could probably mandate the use of a common heap, though, so let's just say yep.
So if I call HeapAlloc() in the library and then later call HeapFree() in the interpreter, that would still be the "right" free(), correct?
Yes, that would always be fine (HeapAlloc and HeapFree are guaranteed to be dynamically linked, since they only exist in kernel32.dll).
I was thinking of the sort of problems that pHeap.e (statically linked) introduces.
On re-examining be_alloc.c I now see that any potential issues with the (Windows-only) cache are rendered pretty insignificant by CACHE_LIMIT.
I had based most of my arguments on a runaway bleed of dll alloc->exe cache or exe alloc->dll cache, but I think these days anyone can live with 4000 (small) allocs they might never get back.
OTOH, were malloc (ie clib, glibc or whatever) statically linked, I simply cannot imagine how they have side-stepped the flaws I've put in pHeap.e, but I rather suspect they have, otherwise the internet would be chock-full of disgruntled programmers moaning about it. Oh wait - there are actually quite a few, eg http://stackoverflow.com/questions/35072500 (first comment on the question, and third paragraph of the first answer) and strangely I have completely failed to prove my point on Windows, yet half-proved it on Linux. Anyway, definitely the sort of thing I meant by a "wrong" free() and a "right" free().
Maybe I should just man up and put pHeap.e in a dll/so, which ceases to be an issue for any app that needs wx.dll, wx.so, iup.dll, libiup.so, or similar anyway.
I might even be capable of using a statically linked pHeap if no dll/so exists (moan about that when opening the above), and perhaps incorporate any needed multi-threading locks into the dynamic one.
Not that any of that, by itself, manages to address any of the fundamental compatibility issues here though, you understand.
From what I see, there's no support in Phix for Euphoria-built shared libraries
Yes, almost exactly the same problem that euconvert fixed: Eu3.1 could not support Eu4.0 dlls and Eu4.0 could not support Eu3.1 dlls.
Quite independently of and quite some time before all this, I have unilaterally decreed that any Phix-built dlls should be callable from C etc, not just Phix.
It seems to me that there are a few options to make wxEuphoria work with Phix:
- Get wxEuphoria to "speak plain C" with just const char*, int, double, etc. This requires more effort in the Euphoria binding code.
I know there are overheads, and it is a Phix (and Eu<=4.0) problem, but that would help.
Regards,
Pete
PS: Apart from the obvious three years of effort you do not want to throw away (I get that, I really do), I'd be interested to hear of any other reasons why you are pushing ahead with this mammoth task instead of cutting your losses and going with the pretty much done and dusted IUP.
