You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using PyO3 in a protocol lib interface to extend it used to Python, since it was developed in Rust. However, my main class in python currently uses multiprocess since it needs to start a server in one process, which makes one process keep locked in that thing. The other ones perform other kind of operations using shared references using an internal system done in rust.
From that, I have two questions:
I need to be able to share the same object that the PyO3 is currently holding for the initialization of the socket. Does it have any internal lock state that might cause conflicts?
Multiprocess isolates it in a process making variables not reached in the other side which was the cause that makes we need to develop a way to share those states, if we switch to use object references in threads instead of processes in python side, we will have access to the states initialized in that references, or it will still be a new reference of that structure that is not initialized yet?
I can provide a representative model of what we have right now. It looks something like that:
But our goal here is to make something like this:
Remove the IPCs, and use a single ref. But since we are dealing with multi threading in the python side and references in the backend, I need to know if I would have some problems with GIL or other internal state inside PyO3 crate. Thanks in advance!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm using PyO3 in a protocol lib interface to extend it used to Python, since it was developed in Rust. However, my main class in python currently uses multiprocess since it needs to start a server in one process, which makes one process keep locked in that thing. The other ones perform other kind of operations using shared references using an internal system done in rust.
From that, I have two questions:
I can provide a representative model of what we have right now. It looks something like that:
But our goal here is to make something like this:
Remove the IPCs, and use a single ref. But since we are dealing with multi threading in the python side and references in the backend, I need to know if I would have some problems with GIL or other internal state inside PyO3 crate. Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions