[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