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

Barak Amar barak.amar at gmail.com
Fri Feb 20 01:06:33 CET 2009

Hi Dirk and Martin,
Thanks Dirk for the Dispose pattern, forgot about it - spending too much
time in C++.

Still don't know the code very well, but in case the C API will return the
qid and we could decode the message type, we may consider warp the byte[] in
a Message class something like:

    public class Message
        public static readonly Message Empty = new Message();
        public static readonly Message Gap = new Message();
        public static readonly Message Delimiter = new Message();

        public byte[] Data { get; set; }

This way we can implement the C# receive:

        public int Receive(out Message msg)
            if (zmq_ == IntPtr.Zero)
                throw new NullReferenceException("queue must be
            IntPtr ptr;
            UInt32 dataSize;
            FreeMsgData freeFunc;
            int qid = 1; czmq_receive(zmq_, out ptr, out dataSize, out

            // check the type and return Message.Gap or Message.Delimiter
            if (ptr == IntPtr.Zero)
                msg = Message.Empty;
                return qid;

            msg = new Message();
            msg.Data = new byte[dataSize];
            Marshal.Copy(ptr, msg.Data, 0, Convert.ToInt32(dataSize));
            if (freeFunc != null)

            return qid;

I'm I lost or this is what you were talking about?

-- Barak

On Thu, Feb 19, 2009 at 5:18 PM, Martin Sustrik <sustrik at fastmq.com> wrote:

> Dirk, Barak,
>  How to tell apart message_gap from non-blocking receive is TBD, I image
>> that a return of zero means no data in non-blocking mode, and returning a
>> null pointer for the data indicates a gap in a given queue.
> Hm, would it be possible to return a triple (int queue-id, int
> message-type, Array<Byte> message-body)? That way the mechanism would be
> future proof allowing for new types of notifications.
> (No idea how .NET handles things like "triple" myself.)
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090220/2bef95a0/attachment.htm>

More information about the zeromq-dev mailing list