B
Bryce Calhoun
Hello,
First of all, this is a .NET 1.1 component I'm creating.
SUMMARY
-----------------------
This component that I'm creating is, for all intents and purposes, a
document parser (I'm actually deserializing a SOAP document into an
object and parsing out the fields, but that's fairly immaterial to this
issue).
This component is instantiated by a VB 6.0 "manager" object, and is
passed by reference a C++ COM data object which, in a separate thread
within the parser, I populate with a bunch of child objects that are
instantiated as necessary. This C++ COM object is basically a very
robust data object, which contains individual children which are record
nodes.
I should mention that I can't change the signature of the method that
receives the parameters, as the interface has been defined and locked
down already.
When I'm done with all my parsing, I invoke my callback method (as I
stated before, the parsing occurs on a separate thread), which then
notifies the manager that the parsing is complete, and that it can save
the contents of the data object (which it already has a handle to).
I've checked the active state of the child thread prior to notifying
the manager object, and it says it's no longer alive. I'm also in the
correct thread (I checked the names I assigned the threads) when I
notify the manager that parsing is complete. Finally, I explicitly set
both my main thread and child threads to have an apartment state of STA
(by decorating the appropriate methods in the main thread).
PROBLEM
---------------------------
My problem is that I get an error within the data object (after it has
been passed back into the VB manager, and my parsing has completed)
having to do with it being unable to write to the system security log.
**This does not appear to be the fault of the application, but rather,
my code's fault, because if I run all my code synchronously, the data
object is able to save everything fine, and is able to write to the
system security log.**
I'm passing in the data object to my child thread within the thread's
constructor (by reference), and, within that separate thread, it's able
to access and manipulate all the properties and methods necessary to
add/delete/modify threats.
QUESTION
--------------------
My question is, do I need to do something special (e.g. some esoteric
marshalling command) to ensure that the COM data object is not going to
get corrupted or become invalid for some reason within the child
thread? What typically is done to COM objects (wrapped in the RCW)
prior to them being passed into separate threads? Am I completely
missing something?
Anything you guys can suggest would be extremely helpful, as this is
pretty much the only issue holding me up now. I could post certain
sub-sections of the code, but it's pretty dense, so I wanted to try a
description of the issue first.
Ideally, someone can tell me exactly what I'm doing wrong because
they've experienced the problem before. Feel free to mock me if I've
done something extraordinarily stupid, as well!
Thanks in advance for any help you can give.
Regards,
Bryce
First of all, this is a .NET 1.1 component I'm creating.
SUMMARY
-----------------------
This component that I'm creating is, for all intents and purposes, a
document parser (I'm actually deserializing a SOAP document into an
object and parsing out the fields, but that's fairly immaterial to this
issue).
This component is instantiated by a VB 6.0 "manager" object, and is
passed by reference a C++ COM data object which, in a separate thread
within the parser, I populate with a bunch of child objects that are
instantiated as necessary. This C++ COM object is basically a very
robust data object, which contains individual children which are record
nodes.
I should mention that I can't change the signature of the method that
receives the parameters, as the interface has been defined and locked
down already.
When I'm done with all my parsing, I invoke my callback method (as I
stated before, the parsing occurs on a separate thread), which then
notifies the manager that the parsing is complete, and that it can save
the contents of the data object (which it already has a handle to).
I've checked the active state of the child thread prior to notifying
the manager object, and it says it's no longer alive. I'm also in the
correct thread (I checked the names I assigned the threads) when I
notify the manager that parsing is complete. Finally, I explicitly set
both my main thread and child threads to have an apartment state of STA
(by decorating the appropriate methods in the main thread).
PROBLEM
---------------------------
My problem is that I get an error within the data object (after it has
been passed back into the VB manager, and my parsing has completed)
having to do with it being unable to write to the system security log.
**This does not appear to be the fault of the application, but rather,
my code's fault, because if I run all my code synchronously, the data
object is able to save everything fine, and is able to write to the
system security log.**
I'm passing in the data object to my child thread within the thread's
constructor (by reference), and, within that separate thread, it's able
to access and manipulate all the properties and methods necessary to
add/delete/modify threats.
QUESTION
--------------------
My question is, do I need to do something special (e.g. some esoteric
marshalling command) to ensure that the COM data object is not going to
get corrupted or become invalid for some reason within the child
thread? What typically is done to COM objects (wrapped in the RCW)
prior to them being passed into separate threads? Am I completely
missing something?
Anything you guys can suggest would be extremely helpful, as this is
pretty much the only issue holding me up now. I could post certain
sub-sections of the code, but it's pretty dense, so I wanted to try a
description of the issue first.
Ideally, someone can tell me exactly what I'm doing wrong because
they've experienced the problem before. Feel free to mock me if I've
done something extraordinarily stupid, as well!
Thanks in advance for any help you can give.
Regards,
Bryce