Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS NetWorkSpaces Coordinated Binding Behavior Other Coordination Patterns NWS Iterators The Web Interface Sleigh Putting It All Together

NWS Iterators

It's also possible to iterate through values in NWS. ifind returns an iterator that returns each value bound to the specified variable:

for v in range(5): ws.store('v', v)
for v in ws.ifind('v'): print v

If you try this, notice that the second loop hangs after printing five values. This is because ifind is waiting for more values. If you use another process to store more values to v, it wakes up and prints them. To signal it to stop, you can delete the binding:

ws.deleteVar('v')

Alternatively, you can use ifindTry, which creates an iterator that terminates as soon as there are no more values. Finally, ifetch and ifetchTry are similar methods that consume the values as they iterate. NWS iterators can only be used on FIFO- or Single-mode variables.

Managing Workspaces

NWS supports multiple workspaces to help organize variables into related groups. We've seen that the constructor takes the name of a workspace as its first argument. It could also take a hostname and a port number to specify the server that hosts the workspace. (Something like this had to be coming. Without it how could we form ensembles with parts running on distinct computers?)

So if multiple processes each execute:

ws = NetWorkSpace('example', serverHost='myhost.mycorp.com')

they would all have access to the same workspace, which is managed by the NWS server accessible through a default port on myhost.

But who would own it? And why would that matter? By default, the process that first mentions the workspace to the server owns it. This matters because we eventually need to clean up. Workspaces and the data in them can be persistent, meaning that they exist until explicitly destroyed. In practice this can lead to a mess, so they are by default transitory—when the process that owns them exits, they are destroyed. Persistence is useful in certain settings and is available via an option to the workspace constructor.

Usually the default ownership policy does the right thing; a master process mentions the NWS first and becomes the owner. Then other processes that use it can come and go without destroying the NWS. Finally, when the master exits, the NWS is cleaned up.

But sometimes you want to be able to mention an NWS without inadvertently becoming the owner, as might happen if an auxiliary process beat the master to the first mention. Declaring the NWS with useUse true indicates that the process doesn't want to own the NWS:

ws = NetWorkSpace('not mine', useUse=True)

Workspace naming presents a bit of a challenge: How can we avoid name collisions? Consider, for example, multiple instances of an ensemble application using the same NWS server. Each NWS workspace object has associated with it a server object (encapsulating the connection to the server managing the workspace). This object provides a mktempWs method that works something like Linux's mkdtemp. It returns a reference to a workspace whose name is guaranteed to be unique on the server. Once we've got our own workspace, we can use variable names within it without worrying about those colliding with some other ensemble program.

Previous Page | 1 NetWorkSpaces | 2 Coordinated Binding Behavior | 3 Other Coordination Patterns | 4 NWS Iterators | 5 The Web Interface | 6 Sleigh | 7 Putting It All Together Next Page

RELATED ARTICLES A Build System for Complex Projects: Part 4 Developing for Mobile Internet Devices: Part 2 Developing for Mobile Internet Devices: Part 1 A Build System for Complex Projects: Part 3 A Build System for Complex Projects: Part 2		TOP 5 ARTICLES No Top Articles.