Re: [ctypes-users] Special use case for ctypes

[Zak S. <zak...@gm...>]

So my thought behind this is that it must be possible... somehow, because
of debuggers. You can attach a debugger to an existing process and see it's
memory and such. I don't need simultaneous access from both the C# wrapper
and the python at the same time. I can have the C# not touch the C while
the python is running. It looks like debuggers do things with signals and
such.

I believe the issue with python for .NET, is that, while the C# would call
my python a little more directly, the python still gets its own instance of
the DLL. Even if I used IronPython, with a totally integrated control, that
is still the same issue.

Thanks for your response! I'm starting to think it's impossible, but not
quite ready to accept that...

On Fri, May 5, 2017 at 12:45 AM, eryk sun <er...@gm...> wrote:

> On Thu, May 4, 2017 at 9:37 PM, Zak Smolen <zak...@gm...> wrote:
> >
> > My application has a C later, accessed by C# layers. I also have a python
> > wrapper for that C layer written using ctypes. I would like to have the
> C#
> > call python scripts which would then, using my library, do things to the
> > same instance of the C DLL as the C# is using.
>
> A DLL can use a shared memory section (i.e. a #pragma data_seg with
> the shared attribute) for data that's shared across all processes, but
> otherwise its global data is private to each process. Use VMMap [1] to
> look at how pages in the .data section are mapped in your DLL.
>
> [1]: https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx
>
> > Also, the CDLL class is able to take a handle pointer to use instead of
> > calling LoadLibrary.
>
> An HMODULE 'handle' is a pointer to the base address where the DLL is
> mapped in the current process. It won't necessarily load at the same
> address in every process. Even if it's mapped at the same address, its
> global .data will be mapped to private pages.
>
> > Anyone have any ideas that may help with this task?
>
> You could look into embedding Python into you .NET process. I thought
> Python for .NET did that, but I've never used it and rarely touch any
> of the .NET universe.
>
> Alternatively, if you're the author of the DLL you could put the
> global variables that need to be shared in a .shared section. But
> there are restrictions on what can be shared. For example, each
> process has its own address space, so sharing pointers should be
> avoided. Also, most handles can't be shared (e.g. kernel handles such
> as File handles are privately defined in the handle table of each
> process).
>