Hi

> What is your purpose of using threads? Overall I've never seen a
> performance gain that warrants the effort of multiple thread
> management. What is good, however, is to separate database activity
> from the UI, and then to synchronise the two when a query has
> completed. This is because the Firebird (and InterBase) API is
> synchronous. A long running query will appear to hang an
> application.

We're trying to lay Firebird under an existing application which
previously used a database(non Sql) which was developed in house.
This application performs database access on multiple threads. I've
written a set of c++ classes which encapsulate the Firebird API, so
far I've only allowed for usage on a single thread(being unsure of
the implications of multiple threads) but to be able to use this
library convienantly in this application I need to make it at least
thread safe.

> The way I would handle this is to give each thread its own handle
> to the library.

I'm not sure exactly what you mean here. I bind to the GDS32.dll in
the following way(I'm afaid its not formated to well here) -

sHandle = LoadLibrary("GDS32.DLL");
if (sHandle == NULL)
{
throw IAPIOErrorImp
(IAPIOErrorImp::kInternalErr_ConsistencyCheckError, "TGdsb::Initialize
", "Could not find or load the GDS32.DLL");
}

if ((_attach_database = (proto_attach_database*)GetProcAddress
(sHandle, "isc_attach_database")) == NULL)
throw IAPIOErrorImp
(IAPIOErrorImp::kInternalErr_ConsistencyCheckError, "TGdsb:Initialize
()", "Entry-point isc_attach_database not found");
-- .. repeated for each entry point required

Now I guess maybe you invisage that the code and static data could be
mapped to the address space more then once, and have its statics
initilized again - effectivly giving each thread its own instance of
the library(own socket connection, etc), I can see that this would
allow for multi thraeded access(effectivly single threaded for each
instance)- But I dont know how this is possible( LoadLibrary as far
as I'm aware would simply return the same handle and addref the dll
in the process if called again?) - and as I said I dont know if this
is even what you mean(I could be missing your point entirely) - so I
would be greatfull for a little more infomation on this technique.

> I guess you could share the libary handle - but then you may be
> advised to wrap the isc_attach_database call in a critical section.

This would appear to be the easiest solution for me, but can I just
confirm with you that if isc_attach_database is wraped in a critical
section - then the other isc_xxx functions that take a db handle will
not need wrapping in a critical section too - as long as each
different thread which makes calls to these methods are passing their
own(not shared with other threads) db handle.

Thanks for the help
Ryan