[zeromq-dev] How do I derive a zactor in CZMQ?

Goswin von Brederlow goswin-v-b at web.de
Thu Aug 14 12:56:39 CEST 2014


Hi,

I'm not sure how zactor in CZMQ is to be used when extending it and
following the coding style in CZMQ. The problem is that czmq seems to
mix the "is a" and "has a" relationships.

- Messages can be send/recv from a zmq socket.
- A zsock is a struct containing a magic and a zmq socket (has a socket)
- Messages can be send/recv from a zsock too (is a socket)
- A zactor is a struct containing a magic and a zsock (has a zsock)
- Messages can be send/recv from a zactor too (is a zsock, is a socket)

This works because the low-level code knows the magics for zsock and
zactor and will extract (recursively) the underlying zmq socket.

So now when I want to extend zactor do I invent a new magic and create
a struct containing the magic and a zactor. Do I add that magic to the
low-level code too? I see two problems with that:

1) checking for each magic value in turn takes time
2) following each pointer to extract the next level takes time

Seems to me like this needs a redesign using a form of inheritance.
Maybe something like this:

struct Base {
  magic_t magic;
  magic_t sub;		/* 0 if not derived */
  base_t base_data;
};

struct Derived {
  struct Base base;	/* base.sub = MAGIC_DERIVED */
  magic_t sub;		/* 0 if not derived */
  derived_t derived_data;
}

Checking for a derived class still has to go through all the magics so
it gets slower as you stack more classes on top of each other. But
that should be rare and only the Derived class needs to know about it.
On the other hand any function acting on Base can act on any derived
class too.

The *_destroy() functions can also refuse to destroy a derived object
and derived_destroy() would set base.sub=0 before calling
base_destroy(). Alternatively the "magic_t sub" could be the address
of the destroy function. This would make them automatically unique and
base_destroy() could call sub() if set to destroy the derived object.
Think virtual destructor.

MfG
	Goswin



More information about the zeromq-dev mailing list