If several threads attempt to create Sybase.Connections simultaneously, then Python hangs.
On my machine I can replicate the problem by using a queue to signal to threads to attempt to connect. Here is sample code.
import threading, Sybase, Queue, time
# we'll signal threads to create a connection via this queue
queue = Queue.Queue()
def connect():
# wait till an item appears in the queue
queue.get()
time.sleep(1)
return Sybase.Connection('ECMPROD', 'ecmquery', 'ecmquery')
# start 5 threads
threads = [threading.Thread(target=connect) for i in range(5)]
for t in threads: t.start()
time.sleep(1)
# kick them all off and then wait for them
print "Signalling ..."
for i in range(5): queue.put(i)
print "Waiting ..."
for i, t in enumerate(threads):
print "Waiting on thread", i
t.join()
This code will hang. If the sleeps are removed, it may hang even before anything is printed (indicating a thread has stolen the GIL I guess)
A limited stack trace shows:
- thread that succeeded ...
...
PyEval_Frame
CS_CONTEXT_ct_con_alloc
conn_alloc
ctx_acquire_gil
PyEval_RestoreThread
PyThread_acquire_lock
- thread that failed, seems to be stuck in conn_alloc
...
PyEval_Frame
CS_CONTEXT_ct_con_alloc
conn_alloc
Logged In: YES
user_id=92432
Originator: NO
I could not reproduce this problem on my system (Python 2.5 with Sybase 15.0). I will try on another system with Sybase 12.5.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=10339
Originator: YES
* Have moved back to open to tag more information on ticket.
* I can still replicate this bug on
Linux 2.6.9-42.ELsmp #1 SMP x86_64 GNU/Linux
SunOS 5.9 Generic_122300-04 sun4u sparc SUNW
Darwin 8.11.1 i386
with the first two linked against OpenClient 12.5, connecting to ASE 12.5, and the latter is linked against FreeTDS connecting to ASE 12.5.
This has been confirmed against two different servers (but both of the same version)