[svn r37693] Some considerations regarding the experimental
Gateway/Remote Path implementation code. Also making it "py.__." importable but not advertising it for 0.9 at all. It's an interesting feature for 1.0 :) --HG-- branch : trunk
This commit is contained in:
parent
58eace43f9
commit
7970591813
|
@ -0,0 +1,24 @@
|
||||||
|
I think the nice code in this directory
|
||||||
|
should be refactored so that you can use
|
||||||
|
it like this:
|
||||||
|
|
||||||
|
rp = gateway.get_remote_path(relpath)
|
||||||
|
|
||||||
|
and relpath could be absolute, relative (should
|
||||||
|
follow remote-platform syntax) or None/"." (the
|
||||||
|
current dir on the other side).
|
||||||
|
|
||||||
|
The tricky part probably is defining sensible
|
||||||
|
setup/teardown semantics with respect to
|
||||||
|
starting the "Path" server on the other side,
|
||||||
|
we at least don't want to have multiple threads
|
||||||
|
that serve path requests and maybe we want
|
||||||
|
to be able to explicitely shutdown a once
|
||||||
|
started RemotePath server (not sure though).
|
||||||
|
|
||||||
|
For a single-threaded py.execnet it might be helpful to be
|
||||||
|
able to install new network messages (which are lower level
|
||||||
|
than remote_exec() and work with callbacks, so don't follow
|
||||||
|
the nice "synchronous" programming model that you get with
|
||||||
|
threads/greenlets/tasklets).
|
||||||
|
|
|
@ -0,0 +1 @@
|
||||||
|
#
|
Loading…
Reference in New Issue