[zeromq-dev] P/Invoke-based CLR access to zeroMQ

[Dirk O. Siebnich]

On Sun, 2009-02-22 at 14:30 +0100, Martin Sustrik wrote:
> One more idea still: If there's a CLI message object as Barak proposed, 
> it can hold the native message_t object and thus we don't have to care 
> about copying/pinning on CLI level at all. Just pass message_size as an 
> argument to the constructor and the object will allocate unmanaged 
> memory itself:
> 
> class Message
> {
> public:
>      Message (int size) : msg (size) {}
> private:
>      message_t msg;
> };
[...]

I thought of this approach, too, but it's probably no worth following,
in any real use-case one would end up copying to a CLR container anyway
in order to fit the type system and be able to work with any other
library functionality. It might be possible to wrap the unmanaged data
type up by implementing all sorts of standard behaviors to make it
transparent, but who is going to do this and support it afterward?

I am attaching a new version of dnzmq.cs that tries to implement the
pinning of managed objects on the GC heap, but right now this WON'T
work, because there is no way to retrieve the GCHandle back from the
object pointer that is at this moment given to the free function
callback. If the C-API would accept a separate token to use as argument
for the free function, this scheme might work. One caveat, though, I
haven't been able to find out whether GC on the GCHandle itself causes
the pinning state to revert, or if this survives until GCHandle.Free is
explicitly invoked. I would hope for the latter, of course.

Does Java have anything that comes even close to this? I think, that
extending the C-API to facilitate these uses for the CLI will not hurt
the chances of integrating better with Java, Python etc. though.

-Dirk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnzmq.cs
Type: text/x-csharp
Size: 5118 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090223/a598a0e0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3223 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090223/a598a0e0/attachment-0001.bin>