I wonder if you can help...
I have a VB6 application and a VC++ COM class. The VB app creates and uses the COM object quite happliy and has worked well for years...
We now see events being received by the VB app out of sequence from the order in which the COM object fired the events.
The COM object receives and processes messages serially. On receiving a message, the COM object fires an event by creating a new thread, marshalling the sink interface pointer to the new thread and continues (leavingtheevent threadto complete the firing process) to pickup and process subsequent messages. When subsequent messages arrive, events are fired similarly (creation of a new event thread).
The issue occurs when messages arrive close in time andconsequentlythe creation ofevent threads occurring close in time.
Event firingthreads are created close in time, but at different times.
Each event thread is running before the subsequent messagesare picked up (and therefore subsequent event firing threads are created)
... and yet, events arrive at the VB app out of sequence.
I have modified the COM class to fire all events in the same STA thread, holding up the main message loop until the STA thread completes... but this takes forever and is too great a performace hit.
I've been reading up on COM apartment models and have so far not come across anything that would explain why events are being received out of sequence... any/all suggestions are very welcome.

thank you,

Getting them out of sequence is the expected behavior. Threads are asynchronous by design, there is no guarantee that they'll progress at the same rate. If sequencing is important, you must ensure this yourself with, say, a thread-safe queue and a single consumer thread that fires the events. Beware that VB6 is notoriously incapable of handling threading correctly, it especially flounders on error handling. Only events raised on the STA are safe.

Please use this forum only to ask questions about managed code and the CLR.

---

Hans Passant.

nobugz is correct in saying that there is no guarantee that your event-firing threads will be processed in the same order they were created. A later thread may very well beat an early thread.

But it is worth noting that whatever threading model you are using in your C++ COM object is of no relevance to the capacity of the VB6 application to use the said COM object. By design, cross-apartment marshaling will occur from your C++ COM object to the VB6 sink without you having to code a single line for this. VB6's inability to multi-thread is of no concern to your particular case.

Again, nobugz is correct in stating that you need to synchronize the events yourself. It seems that getting the events fired in the incorrect order messes things up. Therefore, it is safe to assume that a set of events can be grouped together under a defined criterion or criteria that you already know (because then you wouldn't be complaining about this). So, my suggestion is that you create one event-firing thread for each set of events, rather than one event-firing thread per single event. This way, related events get serialized into the same event-firing thread, therefore ensuring the proper firing order. Note that you will also have to set in place some sort of "event set ID" to be able to identify a particular set of events from another set of events that might be being fired by another event-firing thread.

If you manage to do this, you'll be in the good side of things once more. BTW, this became a problem because... ?? Did you move from a single-core machine to a multi-core machine? Just curious. :-)

---

MCP