I don't think you need to restructure things unless your DLL is spawning
different threads and running things asynchroneously. Usually a DLL will
just receive a call and perform actions according to the calling
application's thread scheduling. In this case it should be fine to have the
handle passed in and acted upon.

If you are spawning your own threads then you should obtain a unique
connection for each thread.

Jason

> -----Original Message-----
> From: Robert martin [mailto:rob@...]
> Sent: Thursday, November 04, 2004 1:32 PM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Passing an IB_Connection to a dll function
>
>
>
> Thanks Jason
>
> Each thread has its own IB_Connection so I suppose that means
> I will have a unique handle for each dll call. However I
> have discovered that the Dll is dynamically created outside
> of the thread so I will have to look at restructuring my code
> (bummer!).
>
> p.s. you may reacall I was having Thread crashes on some
> machines last week. It took me a week but it turned out to
> be an old BDE API call in some inherited code ! The
> application would work fine on most machines because they had
> all had the BDE installed for our old DBase code. It took me
> days to find, perhaps I need more faith in IBO / Firebird :)
>
> Rob Martin
> Software Engineer
>
> phone 03 377 0495
> fax 03 377 0496
> web www.chreos.com
> Wild Software Ltd
> ----- Original Message -----
> From: Jason Wharton
> To: IBObjects@yahoogroups.com
> Sent: Friday, November 05, 2004 9:15 AM
> Subject: RE: [IBO] Passing an IB_Connection to a dll function
>
>
> Just make sure you don't have different threads acting upon the same
> connection handle at a time. To my knowledge the
> connection handle has not
> been made thread safe, and even if they did, it would
> probably be just to
> serialize access anyway, which defeats the benefit of
> allowing multiple
> threads to access it simultaneously.
>
> Someone please correct me if I'm wrong, as it certainly
> could be possible
> for the connection handle to allow asynchroneous access to
> it at some point.
>
> Jason Wharton
>