Thread-safe callbacks and VB?
| Author |
Message |
|
ActiveInstall.co
#1 / 6
|
 Thread-safe callbacks and VB?
Hi All,
I have a VB App which uses the Windows Installer API extensively. I created
a callback function in the vb app to allow the engine to send certain
messages to my app. Problem is that when the callback is called, it is
executing on a different thread, which subtly wreaks havoc on my app,
eventually crashing it.
My solution is to create a simple ATL object to mange the callbacks for me
and raise events back to my app.
The vb app creates an instance of the object and tells the object to
initialize the callback. The object registers it's callback function with
windows installer. When a message is received by the callback function, it
is then raised to the vb app. The result returned from the vb app is then
sent back to windows installer.
So, my questions are:
1. Is this a good thread-safe approach?
2. How do I call an event in my ATL component from outside the class? What
I mean is that the callback function has to raise the event, but it's not a
member of the class with the event so I can't call the function that raises
it.
--
R. Michael Sanford
ActiveInstall, Inc.
Coming soon: http://www.*-*-*.com/
Harness the power of Windows Installer without limitations!
Ask me about no obligation pre-release price reservations!
|
| Sun, 11 Jul 2004 00:53:49 GMT |
|
 |
|
Igor Tandetni
#2 / 6
|
Thread-safe callbacks and VB?
For thread-safety issues, see http://www.mvps.org/vcfaq/com/1.htm.
In most cases, when you install a callback you pass an application-defined value to the function, which is then passed back to the callback. E.g. MsiSetExternalUI accepts pvContext parameter, which is then passed to your INSTALLUI_HANDLER callback. You can pass "this" pointer of your class there.
--
With best wishes,
Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken
Hi All,
I have a VB App which uses the Windows Installer API extensively. I created
a callback function in the vb app to allow the engine to send certain
messages to my app. Problem is that when the callback is called, it is
executing on a different thread, which subtly wreaks havoc on my app,
eventually crashing it.
My solution is to create a simple ATL object to mange the callbacks for me
and raise events back to my app.
The vb app creates an instance of the object and tells the object to
initialize the callback. The object registers it's callback function with
windows installer. When a message is received by the callback function, it
is then raised to the vb app. The result returned from the vb app is then
sent back to windows installer.
So, my questions are:
1. Is this a good thread-safe approach?
2. How do I call an event in my ATL component from outside the class? What
I mean is that the callback function has to raise the event, but it's not a
member of the class with the event so I can't call the function that raises
it.
--
R. Michael Sanford
ActiveInstall, Inc.
Coming soon: http://www.activeinstall.com
Harness the power of Windows Installer without limitations!
Ask me about no obligation pre-release price reservations!
|
| Sun, 11 Jul 2004 03:36:46 GMT |
|
|
|
ActiveInstall.co
#3 / 6
|
Thread-safe callbacks and VB? So your saying to reinflate the class from the pointer while in the callback, then raise the event? Also, are you telling me that the same thread issue exists in ATL? I
understand the solution (conceptually), but was under the impression that
with ATL I wouldn't have to get fancy to make this work.
I truly appreciate any help you can offer with this as I am a VB guy and
know very little about ATL.
--
R. Michael Sanford
ActiveInstall, Inc.
Coming soon: http://www.activeinstall.com
Harness the power of Windows Installer without limitations!
Ask me about no obligation pre-release price reservations!
For thread-safety issues, see http://www.mvps.org/vcfaq/com/1.htm.
In most cases, when you install a callback you pass an application-defined
value to the function, which is then passed back to the callback. E.g.
MsiSetExternalUI accepts pvContext parameter, which is then passed to your
INSTALLUI_HANDLER callback. You can pass "this" pointer of your class there.
--
With best wishes,
Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat, and
wrong." H.L. Mencken
Hi All,
I have a VB App which uses the Windows Installer API extensively. I
created
a callback function in the vb app to allow the engine to send certain
messages to my app. Problem is that when the callback is called, it is
executing on a different thread, which subtly wreaks havoc on my app,
eventually crashing it.
My solution is to create a simple ATL object to mange the callbacks for me
and raise events back to my app.
The vb app creates an instance of the object and tells the object to
initialize the callback. The object registers it's callback function with
windows installer. When a message is received by the callback function,
it
is then raised to the vb app. The result returned from the vb app is then
sent back to windows installer.
So, my questions are:
1. Is this a good thread-safe approach?
2. How do I call an event in my ATL component from outside the class?
What
I mean is that the callback function has to raise the event, but it's not
a
member of the class with the event so I can't call the function that
raises
it.
--
R. Michael Sanford
ActiveInstall, Inc.
Coming soon: http://www.activeinstall.com
Harness the power of Windows Installer without limitations!
Ask me about no obligation pre-release price reservations!
|
| Sun, 11 Jul 2004 04:21:47 GMT |
|
|
|
Igor Tandetni
#4 / 6
|
Thread-safe callbacks and VB?
Quote: > So your saying to reinflate the class from the pointer while in the
> callback, then raise the event?
Yep. Why not? Basically, you don't have much choice. Quote: > Also, are you telling me that the same thread issue exists in ATL? I
> understand the solution (conceptually), but was under the impression
that
> with ATL I wouldn't have to get fancy to make this work.
The issue has nothing to do with ATL and everything to do with Installer API. If Installer calls callbacks on the wrong thread (I'll take your word on it, though I have my doubts), it will continue to call them on the wrong thread whether they are implemented in VB or in C++ or in any other language. The difference is there's no way in VB to handle this gracefully, while in C++ you can take measures to be thread-safe. The purpose of intermediate C++ layer, then, is to switch the callback to the main thread so that VB can deal with it - or else I completely misunderstand your problem. Face it - you are called from the wrong thread, you want to process the
callback on the right thread - there has to be thread switching code in
there somewhere, and you are going to be the one who writes this code,
no way around it.
--
With best wishes,
Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken
|
| Sun, 11 Jul 2004 04:45:37 GMT |
|
|
|
ActiveInstall.co
#5 / 6
|
Thread-safe callbacks and VB? Ok, thanks for clearing that up for me. I'm just troubled by the task of getting back on the right thread... FYI, calling GetCurrentThreadId() inside and outside of the callback yield
different results, so I'm pretty sure what I said is true. Why do you doubt
it? Have you worked with it before? As I said, I could be mistaken, but I
don't think so...
--
R. Michael Sanford
ActiveInstall, Inc.
Coming soon: http://www.activeinstall.com
Harness the power of Windows Installer without limitations!
Ask me about no obligation pre-release price reservations!
Quote:
> > So your saying to reinflate the class from the pointer while in the > > callback, then raise the event? > Yep. Why not? Basically, you don't have much choice.
> > Also, are you telling me that the same thread issue exists in ATL? I
> > understand the solution (conceptually), but was under the impression
> that
> > with ATL I wouldn't have to get fancy to make this work.
> The issue has nothing to do with ATL and everything to do with Installer
> API. If Installer calls callbacks on the wrong thread (I'll take your
> word on it, though I have my doubts), it will continue to call them on
> the wrong thread whether they are implemented in VB or in C++ or in any
> other language. The difference is there's no way in VB to handle this
> gracefully, while in C++ you can take measures to be thread-safe. The
> purpose of intermediate C++ layer, then, is to switch the callback to
> the main thread so that VB can deal with it - or else I completely
> misunderstand your problem.
> Face it - you are called from the wrong thread, you want to process the
> callback on the right thread - there has to be thread switching code in
> there somewhere, and you are going to be the one who writes this code,
> no way around it.
> --
> With best wishes,
> Igor Tandetnik
> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken
|
| Sun, 11 Jul 2004 05:24:25 GMT |
|
|
|
Igor Tandetni
#6 / 6
|
Thread-safe callbacks and VB? I have never worked with Installer API in particular, but usually various Windows APIs are carefully designed in such a way as to avoid calling the callback on a thread different from the one that installed it. There are exceptions however (e.g. timeSetEvent), so I am prepared to trust you on this. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken
Quote: > Ok, thanks for clearing that up for me. I'm just troubled by the task of > getting back on the right thread... > FYI, calling GetCurrentThreadId() inside and outside of the callback
yield
> different results, so I'm pretty sure what I said is true. Why do you
doubt
> it? Have you worked with it before? As I said, I could be mistaken,
but I
> don't think so...
> --
> R. Michael Sanford
> ActiveInstall, Inc.
> Coming soon: http://www.activeinstall.com
> Harness the power of Windows Installer without limitations!
> Ask me about no obligation pre-release price reservations!
message
> > > So your saying to reinflate the class from the pointer while in
the
> > > callback, then raise the event?
> > Yep. Why not? Basically, you don't have much choice.
> > > Also, are you telling me that the same thread issue exists in ATL?
I
> > > understand the solution (conceptually), but was under the
impression
> > that
> > > with ATL I wouldn't have to get fancy to make this work.
> > The issue has nothing to do with ATL and everything to do with
Installer
> > API. If Installer calls callbacks on the wrong thread (I'll take
your
> > word on it, though I have my doubts), it will continue to call them
on
> > the wrong thread whether they are implemented in VB or in C++ or in
any
> > other language. The difference is there's no way in VB to handle
this
> > gracefully, while in C++ you can take measures to be thread-safe.
The
> > purpose of intermediate C++ layer, then, is to switch the callback
to
> > the main thread so that VB can deal with it - or else I completely
> > misunderstand your problem.
> > Face it - you are called from the wrong thread, you want to process
the
> > callback on the right thread - there has to be thread switching code
in
> > there somewhere, and you are going to be the one who writes this
code,
> > no way around it.
> > --
> > With best wishes,
> > Igor Tandetnik
> > "For every complex problem, there is a solution that is simple,
neat,
> > and wrong." H.L. Mencken
|
| Sun, 11 Jul 2004 05:30:52 GMT |
|
| |
|
