Hi Stephan,
sorry for jumping in late; see my comments inline...
Stephan Bergmann wrote On 03/17/06 15:59,:
Kay Ramme - Sun Germany - Hamburg wrote:
Stephan,
Stephan Bergmann wrote:
2 Add rtl_allocateExecutableMemory to rtl/alloc.h, which internally
uses the same logic as rtl_allocateMemory, but works on a second set
of memory, independent of the original set of memory managed by plain
rtl_allocateMemory (and the second set of memory would be executable,
while the original set would not be). Pro: general solution, re-uses
existing program logic, does not make too much memory executable.
Con: extends rtl/alloc.h interface, complicates rtl/alloc.
Matthias Huetsch is AFAIK implementing this API for rtl anyway. So, I
suggest to go with this approach.
With which motivation, Matthias?
Part of my motivation is the issue that you mentioned in the email that
started this thread, i.e. issue 47132 (and its predecessor issue 25250,
that has been workarounded for OOo 1.1.1 as you described under your
topic 1).
The primary motivation though is that I am currently fixing a couple of
performance issues with the existing allocators (rtl_allocateMemory and
class FixedMempool). To start with this, I wrote down a short list of
requirements for allocators, and your issue is on that list, of course.
AFAIK bridges/cpp_uno is the only
place where executable memory is needed.
Yes, that's true. There are no other consumers of such an API right now.
Or are we about to fix the
same issue simultaneously?
Yes, looks like we're doing some overlapping work here. More precisely,
I'm going to offer the functionality that you need to fix your issue.
So, I guess we better start to coordinate our work here.
-Stephan
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
