I'm the one who posted ticket 1601.
I have a multithreaded sqlite tcp server, and it ran fine with 2.8.x and 3.x
versions, but this "feature" is a stopper for me.
I think there is no difference using a dll or not, there is no way to free
that thread memory allocated, since that function it uses static variables.
Some have stated using DLL_THREAD_DETACH, but this only works (in case it
does work) using the dll, if linked statically it keeps leaking memory.
As drh stated:
"In the unix world using pthreads, when you allocate
thread-local storage, you specify a callback function
to delete the storage when the thread terminates.
This callback is the second argument..."
Ok, and what is it suppose to do that callback being that info internal to
sqlite, and thus not exposed?
The problem arises when sqlite uses (malloc) thread memory but itself does
not create/terminate threads.
An application that uses sqlite is the one that knows about threads,
modules, libraries, etc. ie., when they are created/terminated, thread id,
priority, library (dll) loading/unloading, and so on.
I've always thought (since I began using sqlite) about a couple of public
functions (and exported in the "def" file) like:
InitSqliteLib and DeInitSqliteLib.
These would take care of all the public variables, hash lists and so forth
to make a clean start and exit.
Extending this, maybe a couple more but for threads, like (exported in the
"def" file):
InitSqliteThread and DeInitSqliteThread.
So right after creating a thread that is going to use sqlite functions, it
would call InitSqliteThread, which would allocate, initialize or whatever it
needs for the current thread, and right before terminating the thread it
would call DeInitSqliteThread.
Same for the InitSqliteLib and DeInitSqliteLib.
This way, it would be possible to get it working using pthreads, Windows
threads and others.
