[pollyp]

Hi,

I'm writing an app that pulls streaming data off a rfcomm connection and writes it to stdout. I'm a Symbian n00b and have read the docs on threading and active object considerations. My app patterns itself after the application skeleton code: I have a main class that manages the Ao_lock and the ui, and a separate threaded class that reads from the socket and uses a callback to send the data. The UI class sits in a loop, waiting to grab the lock before writing the data, and its callback signals() the lock.

So here's my problem: the socket recv call generates a "App closed PyThread!" message. If I comment out the recv and just send test data back, everything works fine.

I'm puzzled about what's going on here. Why would PyThread close my app based on a socket.recv call? Any hints about what I should try next?

Thanks,

Polly

[jplauril]

Originally posted by pollyp
Hi,

I'm writing an app that pulls streaming data off a rfcomm connection and writes it to stdout. I'm a Symbian n00b and have read the docs on threading and active object considerations. My app patterns itself after the application skeleton code: I have a main class that manages the Ao_lock and the ui, and a separate threaded class that reads from the socket and uses a callback to send the data. The UI class sits in a loop, waiting to grab the lock before writing the data, and its callback signals() the lock.

So here's my problem: the socket recv call generates a "App closed PyThread!" message. If I comment out the recv and just send test data back, everything works fine.

I'm puzzled about what's going on here. Why would PyThread close my app based on a socket.recv call? Any hints about what I should try next?

Thanks,

Polly

Could you post your code here? The first idea that comes to my mind is that you may be inadvertently trying to use a native object from a different thread than it was created in.

[pollyp]

Your first guess was very good indeed. :^)

I was creating the socket in the class's init method, then starting the new thread with a method that did the actual receive. Moving the socket creation into the same thread solved my problem. Even though other instance objects seem to behave well across thread creation, it appears that's not true of socket objects.

Thanks!

Polly

[jplauril]

Originally posted by pollyp
Your first guess was very good indeed. :^)

I was creating the socket in the class's init method, then starting the new thread with a method that did the actual receive. Moving the socket creation into the same thread solved my problem. Even though other instance objects seem to behave well across thread creation, it appears that's not true of socket objects.

As a general rule, none of the Python objects that wrap a native Symbian resource are safe to use from a different thread that where they were created in. This applies at least to socket, e32db (and indirectly to e32dbm and anydbm) and appuifw.