[zeromq-dev] Windows and PGM

[Brian Granger]

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?

Cheers,

Brian

> Any thoughts?
>
> Martin
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com