Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: where is _pyroClaimOwnership after Pyro5.api.expose? #75

Closed
jamesbraza opened this issue Jan 13, 2023 · 3 comments
Closed

Question: where is _pyroClaimOwnership after Pyro5.api.expose? #75

jamesbraza opened this issue Jan 13, 2023 · 3 comments

Comments

@jamesbraza
Copy link

Let's say I have a minimal API:

import Pyro5.api

@Pyro5.api.expose
class Foo:
    pass

foo = Foo()

I am trying to use _pyroClaimOwnership() on foo above, but am getting an AttributeError:

Traceback (most recent call last):
  File "C:\path\to\venv\lib\site-packages\IPython\core\interactiveshell.py", line 3442, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-1-8faed6eb39a3>", line 1, in <module>
    foo._pyroClaimOwnership()
AttributeError: 'Foo' object has no attribute '_pyroClaimOwnership'

How do exposed API's call _pyroClaimOwnership()?

@irmen
Copy link
Owner

irmen commented Jan 13, 2023

_pyroClaimOwnership is a method on a proxy, not on a Pyro server object.
Look at various examples that use it, but mainly the "threadproxysharing" example.

@irmen irmen closed this as completed Jan 13, 2023
@jamesbraza
Copy link
Author

Hi @irmen thank you for the response! Just a brief follow up question, and fyi I am coming from this issue where I am trying to interact with an OpcDaClient (Pyro5.api.expose) on multiple threads.

Is there some way to hand ownership of a Pyro server object to another thread? Thank you in advance for your help if you can provide any further guidance.

@irmen
Copy link
Owner

irmen commented Jan 16, 2023

@jamesbraza There is no concept of exclusive server object ownership in Pyro5 natively. Server object instance(s) - or rather, preferably, classes - are made available to be called concurrently by whatever client can create a proper proxy to call it. If you want to somehow limit the concurrency on objects, you have to control it using the behavior decorator on the server object, and/or roll your own client/server "pair" protocol somehow perhaps.

I've talked about this a bit more in replies to other past issues for instance here - see there for some relevant doc links

and be sure to study the "instancemode" and "usersession" examples, amongst others

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants