| Groups | Blog | Home |
dotnet interop : .NET events do not execute on primary thread
objects you create are STA COM objects. This is what caused the events to be marshaled back to the primary thread. .NET objects have no concept of thread affinitiy [1]. The best way to view a .NET object is that it is a MTA object that aggregates the free threaded marshaller, (or that it lives in the thread nuetral apartment). You will have to manually Marshal these events back to the foreground thread. [1] Technically ContextBound objects do have a concept of thread affinity but that's not relevant in this scenario. -- Jared Parsons [MSFT] jaredpar@online.microsoft.com http://blogs.msdn.com/jaredpar "This posting is provided "AS IS" with no warranties, and confers no rights" [quoted text, click to view] "George" <geobier@newsgroup.nospam> wrote in message news:u07B$UOrFHA.332@tk2msftngp13.phx.gbl... > My .NET application handles events from an out-of-proc COM server. These > events do not execute on the app's primary thread, however. Is this a > consequence of COM Interop or can this be controlled? (The .NET app is > configured to run in a STA.) In a VB6 program, the events are executed on > the primary thread. Thanks for the help. > >
My .NET application handles events from an out-of-proc COM server. These
events do not execute on the app's primary thread, however. Is this a consequence of COM Interop or can this be controlled? (The .NET app is configured to run in a STA.) In a VB6 program, the events are executed on the primary thread. Thanks for the help.
Hi George,
I think cross-apartment marshaling was to provide the ability to do COM call when they lives in the different apartment. So cross-apartment do will have some performance hit, but that is necessary when we have to do cross-apartment marshaling, because the COM call between apartments is common. We can not make sure all the COM call occur on the same thread, that will limit the COM's ability. Also the .NET Interop will also need some more effort to do the COM/.NET type converting and parameter passing.... Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
Thanks for the explanation. Switching to the primary thread to handle the
event solved the original problem, which was slow execution on in-proc, apartment-threaded COM server methods. (Roughly 80 times faster on the primary thread!) Thinking that cross-apartment marshaling was responsible, I changed the in-proc server to the free-threaded model, but the timings didn't improve. Was cross-apartment marshaling a bad theory or is .NET/COM Interop somehow affecting this? Thanks again for the help. [quoted text, click to view] "Jared Parsons [MSFT]" <jaredpar@online.microsoft.com> wrote in message news:%23cuSvsOrFHA.304@TK2MSFTNGP11.phx.gbl... > This is one major difference between VB6 and .NET. In VB6 all of the > objects you create are STA COM objects. This is what caused the events to > be marshaled back to the primary thread. .NET objects have no concept of > thread affinitiy [1]. The best way to view a .NET object is that it is a > MTA object that aggregates the free threaded marshaller, (or that it lives > in the thread nuetral apartment). > > You will have to manually Marshal these events back to the foreground > thread. > > [1] Technically ContextBound objects do have a concept of thread affinity > but that's not relevant in this scenario. > > -- > Jared Parsons [MSFT] > jaredpar@online.microsoft.com > http://blogs.msdn.com/jaredpar > "This posting is provided "AS IS" with no warranties, and confers no > rights" > "George" <geobier@newsgroup.nospam> wrote in message > news:u07B$UOrFHA.332@tk2msftngp13.phx.gbl... >> My .NET application handles events from an out-of-proc COM server. These >> events do not execute on the app's primary thread, however. Is this a >> consequence of COM Interop or can this be controlled? (The .NET app is >> configured to run in a STA.) In a VB6 program, the events are executed >> on >> the primary thread. Thanks for the help. >> >> > >
I'm missing something here, you are talking about an out-proc COM server, in
this scenario there is no cross-apartment marshaling involved, all there is is cross-process marshaling over DCOM which is allways much slower than in-proc marshaling between incompatible apartments. Question is what out-proc server are you talking about? Is this a VB6 ActiveX server? Willy. [quoted text, click to view] "George" <geobier@newsgroup.nospam> wrote in message news:euTOpEcrFHA.3068@TK2MSFTNGP14.phx.gbl... > Thanks for the explanation. Switching to the primary thread to handle the > event solved the original problem, which was slow execution on in-proc, > apartment-threaded COM server methods. (Roughly 80 times faster on the > primary thread!) > > Thinking that cross-apartment marshaling was responsible, I changed the > in-proc server to the free-threaded model, but the timings didn't improve. > Was cross-apartment marshaling a bad theory or is .NET/COM Interop somehow > affecting this? Thanks again for the help. > > > "Jared Parsons [MSFT]" <jaredpar@online.microsoft.com> wrote in message > news:%23cuSvsOrFHA.304@TK2MSFTNGP11.phx.gbl... >> This is one major difference between VB6 and .NET. In VB6 all of the >> objects you create are STA COM objects. This is what caused the events >> to be marshaled back to the primary thread. .NET objects have no concept >> of thread affinitiy [1]. The best way to view a .NET object is that it >> is a MTA object that aggregates the free threaded marshaller, (or that it >> lives in the thread nuetral apartment). >> >> You will have to manually Marshal these events back to the foreground >> thread. >> >> [1] Technically ContextBound objects do have a concept of thread affinity >> but that's not relevant in this scenario. >> >> -- >> Jared Parsons [MSFT] >> jaredpar@online.microsoft.com >> http://blogs.msdn.com/jaredpar >> "This posting is provided "AS IS" with no warranties, and confers no >> rights" >> "George" <geobier@newsgroup.nospam> wrote in message >> news:u07B$UOrFHA.332@tk2msftngp13.phx.gbl... >>> My .NET application handles events from an out-of-proc COM server. >>> These >>> events do not execute on the app's primary thread, however. Is this a >>> consequence of COM Interop or can this be controlled? (The .NET app is >>> configured to run in a STA.) In a VB6 program, the events are executed >>> on >>> the primary thread. Thanks for the help. >>> >>> >> >> > >
Hello George,
I am reviewing the issue thread. Do you still have more concerns on it? If there is any question, please feel free to post here and we will follow up. Thanks very much. Best regards, Yanhong Huang Microsoft Community Support Get Secure! ¨C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! -http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as p&SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Hi
Thanks for your updated! Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
In handling a COM event from the out-of-proc server, the app calls a method
on an in-proc server. This method executes more slowly when called from the event handler than it does if called from the app's primary thread. I suspected marshaling was responsible since the event handler thread (affiliated with an MTA) was using a COM object created in a STA. Creating the in-proc COM object in an MTA however, did not improve performance. [quoted text, click to view] "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message news:esjVZ7wrFHA.1252@TK2MSFTNGP09.phx.gbl... > I'm missing something here, you are talking about an out-proc COM server, > in this scenario there is no cross-apartment marshaling involved, all > there is is cross-process marshaling over DCOM which is allways much > slower than in-proc marshaling between incompatible apartments. > Question is what out-proc server are you talking about? Is this a VB6 > ActiveX server? > > Willy. > > "George" <geobier@newsgroup.nospam> wrote in message > news:euTOpEcrFHA.3068@TK2MSFTNGP14.phx.gbl... >> Thanks for the explanation. Switching to the primary thread to handle >> the event solved the original problem, which was slow execution on >> in-proc, apartment-threaded COM server methods. (Roughly 80 times faster >> on the primary thread!) >> >> Thinking that cross-apartment marshaling was responsible, I changed the >> in-proc server to the free-threaded model, but the timings didn't >> improve. Was cross-apartment marshaling a bad theory or is .NET/COM >> Interop somehow affecting this? Thanks again for the help. >> >> >> "Jared Parsons [MSFT]" <jaredpar@online.microsoft.com> wrote in message >> news:%23cuSvsOrFHA.304@TK2MSFTNGP11.phx.gbl... >>> This is one major difference between VB6 and .NET. In VB6 all of the >>> objects you create are STA COM objects. This is what caused the events >>> to be marshaled back to the primary thread. .NET objects have no >>> concept of thread affinitiy [1]. The best way to view a .NET object is >>> that it is a MTA object that aggregates the free threaded marshaller, >>> (or that it lives in the thread nuetral apartment). >>> >>> You will have to manually Marshal these events back to the foreground >>> thread. >>> >>> [1] Technically ContextBound objects do have a concept of thread >>> affinity but that's not relevant in this scenario. >>> >>> -- >>> Jared Parsons [MSFT] >>> jaredpar@online.microsoft.com >>> http://blogs.msdn.com/jaredpar >>> "This posting is provided "AS IS" with no warranties, and confers no >>> rights" >>> "George" <geobier@newsgroup.nospam> wrote in message >>> news:u07B$UOrFHA.332@tk2msftngp13.phx.gbl... >>>> My .NET application handles events from an out-of-proc COM server. >>>> These >>>> events do not execute on the app's primary thread, however. Is this a >>>> consequence of COM Interop or can this be controlled? (The .NET app is >>>> configured to run in a STA.) In a VB6 program, the events are executed >>>> on >>>> the primary thread. Thanks for the help. >>>> >>>> >>> >>> >> >> > >
Hi Yanhong Huang,
Thanks for checking. We have opened a case with Microsoft Support on this and are awaiting further information. George [quoted text, click to view] "Yan-Hong Huang[MSFT]" <yhhuang@online.microsoft.com> wrote in message news:D%23wEJdcsFHA.1208@TK2MSFTNGXA01.phx.gbl... > Hello George, > > I am reviewing the issue thread. Do you still have more concerns on it? If > there is any question, please feel free to post here and we will follow > up. > > Thanks very much. > > Best regards, > Yanhong Huang > Microsoft Community Support > > Get Secure! ¨C www.microsoft.com/security > Register to Access MSDN Managed Newsgroups! > -http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as > p&SD=msdn > > This posting is provided "AS IS" with no warranties, and confers no > rights. >
Hi George,
Thanks very much for your update. If it is convenient for you, could you please update the community with the result after you communicate with support team? Hopefully the community can benefit from it. Thanks again for participating the community. Have a nice day. Best regards, Yanhong Huang Microsoft Community Support Get Secure! ¨C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! -http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as p&SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |