Subject | Re: [ib-support] Threads and GDS32.dll |
---|---|
Author | Paul Reeves |
Post date | 2002-05-03T12:16:53Z |
On Fri, 03 May 2002 11:54:50 -0000, ryanb486 wrote:
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.
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.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase
>Hello,Yes.
>
>I've read somewhere that it is safe if each thread uses its own
>connection. Does anyone know if this is correct?
>
>If So - Should I ensure that only one thread at a time calls in toThe way I would handle this is to give each thread its own handle to the library.
>isc_attach_database - And if so is it then safe to call the other
>api function on mutiple threads simultaniously if each different
>thread is passing a different connection handle.
>
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.
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.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase