Le 26/09/2012 17:48, Zorro a écrit :
Le 26/09/12 17:09, Miro Kropáček a
écrit :
In
theory, there are many advantages to providing callback to
client's MiNTlib:
1) You can safely use the mintlib's functions into the
LDG.
2) The context should be the same, so you can share a
memory allocation without using MEM.LDG or others "tricks"
like the SHM.
3) The binaries are a lot smaller.
Sure. That's why I started with that, it eliminated all
strange crashes I ever encountered.
When you will finish your work, this will be a little revolution
for the application's coders.
A plugin based application will be written easily as a normal
application... No more MEM.LDG, libshare and
others dirty jobs.
mem.ldg and libshare have never been need. MEM.LDG is only a small
lib to provide libc like api for memory management without libc
thats all.
Congratulation !
In
zView Beta 8, do you use the new LDG format? ( because in
the changelog, you say that men.ldg is no longer needed).
No no, that's still the old format, I think mem.ldg was
removed because it was not actively used or so.
Yes it is !
For example, look inside the file "pic_load.c", zView send memory
pointers to the codecs. If this memory are allocated with the
standard malloc(), the application can/will become unstable.
You can send memory allocated by malloc() to the codec without
problem and use it but of course you can't use in the codec libc
function like realloc(), free() because if you not share libc of the
application the libc of the codec don't know how to manage it
because it not allocate itself but this is the only restriction that
look simple. If you wan't manage the memory bloc you should send
memory alloc with system call (Malloc or Mxalloc) and manage it with
system call.
Olivier
--
Zorro
|