threading support

[djs]

I've been trying to use rpyc as a bridge to remote serial ports and it
seems to work really well, with one small issue. I instantiate remote
objects that create background monitor threads for each serial port so
I can buffer the input and watch for certain strings. However, once I
run a script that starts this, when it terminates, the rpyc server
doesn't seem to clean up the objects properly. The threads remaining
running (thus blocking the serial ports) and also the thread that was
created for the remote client remains in the _bg_register() method
loop. The __del__ methods of the created objects don't seem to get
called until I terminate the server.

Any thoughts on what might be causing this? Are there any restrictions
on how you can use threads with rpyc? I can try to write a small
example if it would be helpful.

Thanks,
Dan

[Tal Einat]

If that's the case then I'm glad I could help!

Add .close() methods to your objects/threads and call them before terminating the server.

Never rely on __del__ for these kind of things. (In fact, try not to rely on __del__ for anything...


The reason is that in Python, variables don't actually "contain" the data, they are only references to the actual object. There can be many different references to the same object, for instance you can have several variables reference a single list:

>>> a = [1,2,3]
>>> b = a
>>> a.append(4)
>>> b
[1, 2, 3, 4]

Now, even if we delete the variable 'a', the underlying list object will continue to exist since it is still referenced by variable 'b':

>>> del a
>>> b
[1, 2, 3, 4]

The same thing is happening on your remote server, although the extra references are not necessarily created implicitly by your code. These references could perhaps be stored somewhere within the mechanics of RPyC. It is best simply not to assume that there are no extra references hanging around somewhere.

- Tal

On Thu, Jun 18, 2009 at 9:27 PM, Dan Savilonis <d...@n-cube.org> wrote:

That does seem to be the problem, though I'm not quite sure I understand why. I did try using del and it didn't help. I'll see if I can figure out a way to properly clean up the threads at the end of the test.

Dan

On Mon, Jun 15, 2009 at 12:47 PM, Tal Einat <tale...@gmail.com> wrote:

I'm not sure this is the problem in your case, I haven't thought it through yet...

Try not relying on __del__ being called, and instead implicitly call a function which will do the cleanup.

The reason I think this might be the problem is the the __del__ method of object is called only when the object is garbage collected, which will never happen as long as a reference to the object is still lying around anywhere. Note that this means the even doing "del x" won't necessarily call x.__del__, since another reference to the object referenced by 'x' may still exist. For this reason Python objects representing things like files and sockets have .close() methods which may be called implicitly.

Hope this helps,

- Tal