[zeromq-dev] Windows and PGM

Martin Sustrik sustrik at 250bpm.com
Thu Mar 25 22:59:09 CET 2010

Brian Granger wrote:
> Martin,
>> One of the things I've been thinking about was how to instantiate devices
>> in-process via API. That would allow say for using a queue device to
>> distribute requests to worker threads (i.e. in-process). The other benefit
>> would be that "implementing the forwarder device in Python" would simply
>> mean calling the particular API.
> Yes, I do think that this makes sense and really that is the goal i
> have of implementing them in python.  It would be great if it was in
> 0MQ itself.
>> The problem I haven't solved yet is how should such API look like. All the
>> ideas I had so far were pretty awkward.
> Hmm, thinking out loud.  Seems like there should be a base C++
> "device_t" class in 0MQ.  This class should be quite simple:  it
> should have a start and a stop method.  These methods should call
> methods that subclasses provide that actually implement the device.
> The device_t class should be thread safe and calling start should do:
> * Start a new application thread that the device will run in.
> * Call the appropriate method of the subclass that starts the event
> loop of the device in the thread.
> * Return immediately.
> Calling stop should do:
> * Stop the devices event loop.
> * Kill the thread.
> Might also have a pause.
> Different subclasses can implement appropriate constructors to pass
> the configuration information to the device.
> The key though, I think, is to run the device in a thread so it can
> have its own event loop.  Not sure, but you might want to even give
> each device its own context.
> Does this make any sense?

Yes, it does. However, what I had problem with is how all that info 
that's currently available in the xml config file should be passed to 
the device class...


More information about the zeromq-dev mailing list