Is this correct? Thanks!

Is this correct? Thanks!

Author

Message

FLD#1 / 5

Is this correct? Thanks!

Hi all and sorry for my english.

1) I have a external DLL (not developed by my) that exports two functions: - Declare Function Run Lib "MyLib.dll" () As Long - Declare Function CallBack Lib "MyLib.dll" (ByVal pFunc As Long, ByVal pArg As Long) As Long where "pFunc" is a function pointer and "pArg" is an general argument. When I call to the function "Run", this one executes its work and calls to the function "pFunc" passing to him the argument "pArg". I want to implement pFunc in Visual Basic, so their declaration is (in a BAS module): "Public Function MyFunction(ByVal pArg As Long) As Integer"

2) I have a VB ActiveX DLL (VB 6 SP5) with a class "MyClass" and a module which contains "MyFunction" implementation. The class have a method "MyRun" with code:

Public Sub MyRun() ' Define the callback and call Run call CallBack(AddressOf MyFunction, ObjPtr(Me)) call Run End Sub

and a Friend Property

Friend Property Get MyProperty() As Long MyProperty = MyValue End Property

"MyFunction" implementation is:

Public Function MyFunction(ByVal pMyClass As Long) As Integer

Dim oMyClass As MyClass Dim ObjCtx As ObjectContext Dim ASPRes As ASPTypeLibrary.Response Dim MyProperty As Long

3) The ActiveX DLL is in a in-process COM+ package and I have an ASP page that creates an MyClass object and calls MyRun Method

This framework works for me, but is correct? Can I have problems in a multithread environment like IIS? Suggestions?

Thanks!

Saludos, Paco

Mon, 29 Dec 2003 15:08:53 GMT

Adrian Batema#2 / 5

Is this correct? Thanks!

Quote:

> Hi all and sorry for my english. [snip]

> This framework works for me, but is correct? > Can I have problems in a multithread environment like IIS? > Suggestions?

The code you included looks correct, certainly as far as a single threaded environment is concerned. Whether or not you have problems with this in a multi-threaded environment such as IIS depends largely upon the implementation of the DLL you are calling into. Is the DLL thread-safe? Not only is it storing the callback function and object reference somewhere that may or may not be thread-safe, the work it is doing may not be thread safe (it may use global variables to perform the work your ask it to).

If the DLL is thread-safe, you shouldn't have a problem, but if it isn't, you'll need to synchronise access to it.

Regards,

Ade.

Mon, 29 Dec 2003 18:26:29 GMT

FLD#3 / 5

Is this correct? Thanks!

The DLL is thread-safe. Thanks for your reply!!

Saludos, Paco.

Quote:

> > Hi all and sorry for my english. > [snip]

> > This framework works for me, but is correct? > > Can I have problems in a multithread environment like IIS? > > Suggestions?

> The code you included looks correct, certainly as far as a single threaded > environment is concerned. Whether or not you have problems with this in a > multi-threaded environment such as IIS depends largely upon the > implementation of the DLL you are calling into. Is the DLL thread-safe? Not > only is it storing the callback function and object reference somewhere that > may or may not be thread-safe, the work it is doing may not be thread safe > (it may use global variables to perform the work your ask it to).

> If the DLL is thread-safe, you shouldn't have a problem, but if it isn't, > you'll need to synchronise access to it.

> Regards,

> Ade.

Mon, 29 Dec 2003 18:47:52 GMT

Mr07#4 / 5

Is this correct? Thanks!

VB coclasses have thread affinity and can run only inside the apartment they were created in. You send the address of your class to the Callback function, so there is not COM marshaling involved. If your Run implementation always calls back from the same thread you will not have any problems, but understand that it is so only concidentally. If there is a chance that the other DLL will create another thread, you will have to call CoInitialize on it and thus end up in an apartment different than the one your object was created in. Calling back to your MyFunction will most likely crash. Even if it works that will be only by chance.

Hope this helps you make a good call about how this might work in a more complex environment.

-- Sanin Saracevic, MCP Lead Software Architect Interland, Inc.

Quote:

> The DLL is thread-safe. > Thanks for your reply!!

> Saludos, > Paco.

> > > Hi all and sorry for my english. > > [snip]

> > > This framework works for me, but is correct? > > > Can I have problems in a multithread environment like IIS? > > > Suggestions?

> > The code you included looks correct, certainly as far as a single threaded > > environment is concerned. Whether or not you have problems with this in a > > multi-threaded environment such as IIS depends largely upon the > > implementation of the DLL you are calling into. Is the DLL thread-safe? > Not > > only is it storing the callback function and object reference somewhere > that > > may or may not be thread-safe, the work it is doing may not be thread safe > > (it may use global variables to perform the work your ask it to).

> > If the DLL is thread-safe, you shouldn't have a problem, but if it isn't, > > you'll need to synchronise access to it.

> > Regards,

> > Ade.

Tue, 30 Dec 2003 01:35:53 GMT

FLD#5 / 5

Is this correct? Thanks!

Thanks Sanin!!

The function "Run" is not developed by my, reason why I cannot determine if this one creates other tasks or no. Nevertheless, in all the tests that I have made "App.ThreadID" in "MyFunction" it is the same one that in "MyRun" reason why I can suppose that the external DLL does not create more tasks.

Thanks once again.

Saludos, Paco.

Quote:

> VB coclasses have thread affinity and can run only inside the apartment they > were created in. You send the address of your class to the Callback > function, so there is not COM marshaling involved. If your Run > implementation always calls back from the same thread you will not have any > problems, but understand that it is so only concidentally. If there is a > chance that the other DLL will create another thread, you will have to call > CoInitialize on it and thus end up in an apartment different than the one > your object was created in. Calling back to your MyFunction will most likely > crash. Even if it works that will be only by chance.

> Hope this helps you make a good call about how this might work in a more > complex environment.

> > > > This framework works for me, but is correct? > > > > Can I have problems in a multithread environment like IIS? > > > > Suggestions?

> > > The code you included looks correct, certainly as far as a single > threaded > > > environment is concerned. Whether or not you have problems with this in > a > > > multi-threaded environment such as IIS depends largely upon the > > > implementation of the DLL you are calling into. Is the DLL thread-safe? > > Not > > > only is it storing the callback function and object reference somewhere > > that > > > may or may not be thread-safe, the work it is doing may not be thread > safe > > > (it may use global variables to perform the work your ask it to).

> > > If the DLL is thread-safe, you shouldn't have a problem, but if it > isn't, > > > you'll need to synchronise access to it.