>an other question: the file ven03.c: > is this a deeper layer than the interfaces (perl, php) itsself?
Yes. It is part of the operating system abstraction layer. The interfaces use only the functions sqlaconnect, sqlarelease, sqlarequest , sqlareceive and a few related ones. > >the real problem seems to me that when more than >8(=firstChunk) connections >are opened, the function sql03_realloc_pool will be called, which >reserves memory for 16 connections copies the old memory and frees it. > >I am pretty sure that this is not threadsafe, and can lead in >SEGFAULTS or >CONNECTION IN WRONG STATE.... when another thread has an >(indirect?) pointer >to a connection_info struct. > >Can anybody give me a hint? It looks as if the connection pool contains an array of connection_info and not and array of connection_info pointer. This means that a realloc will invalidate any current pointers. Code above the level of the afore mentioned sql* functions will use a handle and not an actual pointer. But if the realloc happens while another thread is inside sqlarequest or sqlareceive, bad things will happen. I'll have a look at what the effort would be to fix this. I'd resent having to downgrade the thread awareness of the python driver. On the other hand, 7.7 will probably get a completely new communication layer designed from the ground up for thread safety. And communication is a very central part of MaxDB, so everyone is conservative about changes. And if I understood your situation right, you're stuck with 7.4 anyway because of the license. Which boils down to: - I'll probably have to fork ven03.c - the changes will be in GPL'ed code Daniel Dittmar -- Daniel Dittmar SAP Labs Berlin [EMAIL PROTECTED] -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
