+++ /dev/null
-# as you can see - the import line now requires even less typing!\r
-from Rpyc import *\r
-c = SocketConnection("localhost")\r
-\r
-#------------------------------------------------------------------------------ \r
-# this demo shows the new `execute` and `namespace` features of rpyc\r
-#------------------------------------------------------------------------------ \r
-\r
-\r
-# the code below will run AT THE OTHER SIDE OF THE CONNECTION... so you'll see\r
-# 'hello world' on the server's console\r
-c.execute("print 'hello world'")\r
-\r
-import sys\r
-c.modules.sys.stdout = sys.stdout\r
-\r
-# and this time, on our console\r
-c.execute("print 'brave new world'")\r
-\r
-# restore that\r
-c.modules.sys.stdout = c.modules.sys.__stdout__\r
-\r
-# anyway, the `execute` method runs the given code at the other side of the connection\r
-# and works in the `namespace` dict. what?\r
-c.execute("x = [1,2,3]")\r
-print c.namespace.x\r
-\r
-# now it makes sense, doesn't it? the 'namespace' attribute is something i called \r
-# AttrFrontend -- it wraps a dict with the attribute protocol, so you can access\r
-# it with the dot notation, instead of the braces notation (more intuitive).\r
-# this namespace works both ways -- executing code affects the namespace, while\r
-# altering the namespace directly also affects it:\r
-c.namespace.x.append(4)\r
-c.execute("x.append(5)")\r
-print c.namespace.x\r
-\r
-# but you should not assign complex objects (not int/float/str, etc) to this namespace\r
-# directy, or NetProxies will be created. there's nothing wrong with that, but keep\r
-# in mind it might cause blocking (and even deadlocks), as i'll explain later.\r
-\r
-# another cool thing i want to show is the second, optional parameter to execute: mode.\r
-# the mode controls how the code is compiled. the default mode is "exec", which means \r
-# it executes the code as a module. the other option is "eval" which returns a value.\r
-# so if you want to _do_ something, like printing of assigning a variable, you do it \r
-# with "exec", and if you want to evaluate something, you do it with "eval"\r
-# for example:\r
-\r
-# this will print None\r
-print c.execute("1+2")\r
-\r
-# while this will print 3\r
-print c.execute("1+2", "eval")\r
-\r
-# but there's a time in a man's life when he asks himself, why the heck? you can, as i \r
-# showed in other places, just do this:\r
-# c.modules.__builtin__.eval("1+2")\r
-# so what's the point? \r
-#\r
-# well, i've been waiting for this question. the rationale behind this seemingly useless \r
-# feature is for times you NEED to have the code executing remotely, but writing a \r
-# dedicated module for it is overdoing it:\r
-# * more files to update ==> more chance that you'll forget to update\r
-# * distributing the module to all of the machines\r
-# * making a mess on the file system\r
-# * it's really not a module... it's just some code that logically belongs to one single \r
-# module, but technical difficulties prevent it\r
-#\r
-# and to show you what i mean -- i want to start a thread on the server, like it did in \r
-# several places over the demos. this thread will send me an event every second. what i \r
-# used to do was, creating another module, like testmodule.py to define the thread \r
-# function, so it will exist on the server, and i could call it.\r
-# if i defined thread_func at the client side, then the thread will block when trying \r
-# to execute the code, because the client holds it. so this new mechanism lets you \r
-# distribute code in a volatile fashion:\r
-# * when the connection is closed, everything you defined is gone\r
-# * no file-system mess\r
-# * no need to distribute files across the network\r
-# * only one place to maintain\r
-\r
-c.execute("""\r
-my_thread_active = True\r
-\r
-def my_thread_func(callback):\r
- import time\r
- from Rpyc import Async\r
-\r
- callback = Async(callback)\r
- while my_thread_active:\r
- callback(time.time())\r
- time.sleep(1)\r
- print "the thread says goodbye"\r
-""")\r
-\r
-def callback(timestamp):\r
- print "the timestamp is", timestamp\r
-\r
-c.modules.thread.start_new_thread(c.namespace.my_thread_func, (callback,))\r
-c.modules.time.sleep(5)\r
-c.namespace.my_thread_active = False\r
-c.close()\r
-\r
-# it's not only for threads of course. there are many times when you NEED the code/objects \r
-# on the remote side. for example:\r
-# * situations that would block (like having the thread func on the client)\r
-# * code that check the type of the object (type or isinstance), and a NetProxy would make\r
-# it cry. DONT CHECK THE TYPE OF OBJECTS, PEOPLE, JUST USE THEM! that's why they invented \r
-# duck-typing. argh.\r
-# * other places i didnt think of as of yet. i want to sleep. leave me alone ;) zzzZZZ\r
-#\r
-# so enjoy!\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
git://git.onelab.eu / monitor.git / blobdiff