jiuyuan
/
test_ok1
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

[svn r37643] stroke the historical notes, and streamlined 

various parts of execnet documentation,
added some api references.

--HG--
branch : trunk
This commit is contained in:
hpk 2007-01-31 00:13:49 +01:00
parent 6aaca64290
commit 97346c8a5a
1 changed files with 27 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
py/doc/execnet.txt
View File

@ -4,7 +4,7 @@ The py.execnet library
.. contents:: .. contents::
.. sectnum:: .. sectnum::
Execnet deals with letting your python programs execute and ``py.execnet`` deals with letting your python programs execute and
communicate across process and computer barriers. At the communicate across process and computer barriers. At the
core it is a very simple and powerful mechanism: executing core it is a very simple and powerful mechanism: executing
source code at "the other side" and communicating with source code at "the other side" and communicating with
@ -15,35 +15,18 @@ in some ways. So some of the described features are not
there yet. You may refer to the `py API`_ reference for there yet. You may refer to the `py API`_ reference for
further information. further information.
The "shpy" way, historical remarks
----------------------------------
Some of you may have seen the pygame-based editor **shpy**
that Armin Rigo, Holger Krekel and Michael Hudson demonstrated
at EuroPython 2004 during the lightning talks. It is a
multiline interactive python environment which allows multiple
remote users to have their own cursors and shared interaction
with the graphical shell which can execute python code, of
course.
**py.execnet** extracts and refines the basic mechanism that
was originally developed from the one-week hack that is the
current **shpy**. No, the latter is not released but hopefully
Armin, Holger and others get to do a second one-week sprint at
some point to be able to release it. If you are interested
drop them a note. This is real fun if you are willing to
bend your mind a bit.
A new view on distributed execution A new view on distributed execution
----------------------------------- -----------------------------------
**py.execnet** takes the view of **asynchronously executing **py.execnet** lets you asynchronously execute source code on
client-provided code fragments** to help address a core remote places. The sending and receiving side communicate via
problem of distributed programs. A core feature of Channels that transport marshallable objects. A core feature
**py.execnet** is that **the communication protocols can be of **py.execnet** is that **the communication protocols can be
defined by the client side**. Usually, with server/client completely defined by the client side**. Usually, with
apps and especially RMI systems you often have to upgrade your server/client apps and especially Remote Method Based (RMI)
server if you upgrade your client. approaches you have to define interfaces and have to
upgrade your server and client and restart both.
What about Security? Are you completely nuts? What about Security? Are you completely nuts?
--------------------------------------------- ---------------------------------------------
@ -68,24 +51,29 @@ With ''py.execnet'' you get the means
High Level Interface: **remote_exec** High Level Interface: **remote_exec**
------------------------------------- -------------------------------------
These gateways offer one main high level interface:: All gateways offer one main high level interface,
e.g.
def remote_exec(source): def remote_exec(source):
"""return channel object for communicating with the asynchronously """return channel object for communicating with the asynchronously
executing 'source' code which will have a corresponding 'channel' executing 'source' code which will have a corresponding 'channel'
object in its executing namespace.""" object in its executing namespace."""
The most important property of execnet gateways is that the With `remote_exec` you send source code to the other
protocol they speak with each other ``is determined by the side and get both a local and a remote Channel_ object,
client side``. If you open a gateway on some server in order which you can use to have the local and remote site
to coordinate with some other programs you determine your communicate data in a structured way.
communication protocol. Multiple clients can run their own
gateway versions in the same remote process (e.g. connecting This approach implements the idea to ``determining
through their version of a SocketGateway). protocol and remote code from the client/local side``.
This makes distributing a program run in an ad-hoc
manner (using e.g. :api:`py.path.SshGateway`) very easy.
You should not need to maintain software on the other sides You should not need to maintain software on the other sides
you are running your code at. you are running your code at, other than the Python
executable itself.
.. _`Channel`:
.. _`channel-api`: .. _`channel-api`:
.. _`exchange data`: .. _`exchange data`:
@ -128,7 +116,8 @@ Here is the current interface::
A remote side blocking on receive() on this channel A remote side blocking on receive() on this channel
will get woken up and see an EOFError exception. will get woken up and see an EOFError exception.
A simple and useful Example for Channels
The complete Fileserver example
........................................ ........................................
problem: retrieving contents of remote files:: problem: retrieving contents of remote files::
@ -155,6 +144,7 @@ problem: retrieving contents of remote files::
# later you can exit / close down the gateway # later you can exit / close down the gateway
contentgateway.exit() contentgateway.exit()
A more complicated "nested" Gateway Example A more complicated "nested" Gateway Example
........................................... ...........................................