[nanomsg] Re: Routing plan
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 13 Feb 2013 07:21:57 +0100
On 12/02/13 20:24, Paul Colomiets wrote:
Btw, in the long term I see devices as something that's managed by admins
rather than by programmers. They should be able to start/stop/move devices
according to actual application needs. Maybe even do all the above from the
administrative console.
So they must have binaries for the devices included, so you don't need
to write any code to spawn a device. Any plans on this?
As for devices, I would go for basically the same thing we had in 0MQ:
int nn_device (int s1, int s2);
The main difference would be conceptual. Back in 0MQ the concept of
device was a fuzzy one. Basically anything that used two sockets
qualified as a device.
With nanomsg the concept of device is stricter. It's a component that
lives in the middle of a single topology. (The idea is to have explicit
topology IDs.)
Btw, that's the main reason why I've split 0MQ's pipline pattern
(push/pull) into fanout and fanin patterns. Now, the worker node in a
pipline is connected to fanin topology on one side and fanout topology
on the other side => it's not a device!
As for executables, it's trivial to just invoke the nn_device function
so it's probably not worth shipping the executables.
Also don't you think that thread per device is too wasteful?
If you share a thread among devices, you have to do scheduling on
nanomsg level. I don't believe we can do it better than OS does. I mean,
there are entire manyears invested in OS schedulers. Why duplicate the work?
Or do you mean, the memory allocated for the thread stacks? I've tried
to avoid recursion in nanomsg, so the stacks should be pretty short.
Hopefully they will fit into single memory page. If you are interested
in this kind of stuff we can start messing with pthread_attr_setstacksize.
Martin
Other related posts:
