Hi,
I found what block my print in my thread.
It s not sql alchemy library, it s MySQLdb...
They import directly in the function, import block print in threads
I modified the library (imports move out of the method) and it works
very well now. I can now run asynchronous queries so my gui don t
Hi again,
I understand all!
SqlAlchemy and MySQLdb don t respect this rule 16.2.9
http://docs.python.org/library/threading.html#threaded-imports
Why? :(
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
Where do you see SQLAlchemy spawning any threads ?Its the responsibility of
the threaded application to make sure all imports occur before threads are
spawned. The documentation you refer to states as much.
On May 2, 2010, at 8:34 AM, christiandemo...@gmail.com wrote:
Hi again,
I
correction, it doesn't even say that. All it says regarding deadlocks is that
an import shouldn't spawn a thread. SQLAlchemy does not spawn any threads
(pretty sure MySQLdb doesn't, either).
On May 2, 2010, at 11:28 AM, Michael Bayer wrote:
Where do you see SQLAlchemy spawning any threads
Hello Michael,
Thx for answer.
Of course, there is no thread in mysqldb
but there is import in function connect line 73 of __init__.py
and line 128 to 132 of connections.py in method __init__(self, *args,
**kwargs):
So when i use connect function in my thread, it blocks because it
encounters
Hi
All it says regarding deadlocks is that an import shouldn't spawn a thread
Can you explain me why import math (whick don t spawn a thread) block this thread (only
one ok appear in terminal)?
When i remove import math, ok appears continuously in term.
I don t understand
class
Ok i found this subject which explain why.
http://www.mail-archive.com/python-...@python.org/msg24747.html
The deadlock happens because strptime has an import inside it, and
recursive imports are not allowed in different threads.
This situation is well known, found a lot of references to this
On Apr 29, 2010, at 3:21 AM, Chris Withers wrote:
Michael Bayer wrote:
if your application keeps a handle on objects after the request is
complete, and then passed them somewhere else, like a background thread or
something, then the subsequent request is going to be potentially touching
