-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Youness Alaoui wrote: > Hi again... > So I've finally managed to figure it out perfectly... I've opened a bug to > the gstreamer project and I've explained the issue here : > http://bugzilla.gnome.org/show_bug.cgi?id=592415
COM threading. In order to use COM functions a thread has to be places into an apartment. Either a single-threaded apartment (STA) or a multithreaded apartment (MTA). You can't be in both. If you make use of the MTA then you have to write your code to be thread-safe. If you use an STA then the COM subsystem will ensure that only one thread will ever make calls you your objects and it serializes all such calls for you. The comments in the gstreamer bug suggest they are using multiple threads but also that they make COM calls from threads that have not joined any apartment. That doesn't sound too good. What that looks like is they didn't work out the details of the marshalling required to have one thread communicate to another using STAs so they bodged it by making it use MTAs and tried to brush it all under the carpet. So aMSN now has two extensions being loaded which are using different threading models and you want to have tkvideo to use an MTA to match gstreamer. It might work out ok but its not been written to be thread safe and we will need to check that the things we are talking to are ok with being in an MTA. When you create an object from a COM initalized thread the subsystem looks up the classes creation parameters and if the COM class is capable of being created in an MTA then it just creates a new object and gives you the interface pointer to use. If the class is marked up as using an STA (which is the most common case) then it will fire up a new STA thread, create the object in that thread and return a marshalled pointer. That is a pointer to a stub object in your apartment. When you make a COM call to the object now you actually call the stub which serializes the paramters into a stream and passes that to the STA. In the STA this is deserialized and the real object method is called and any result serialized before being passed back to the calling stub object. This adds quite a bit of overhead. I looked at the filter graph co-class and its model is set as 'both'. That means it is happy to be created in either an STA or MTA. CaptureGraphBuilder2 is 'both' as well as is the VideoMixingRenderer class. So looks like all the DirectShow objects can be created in an MTA. Tcl likes to be on one thread so you'd need to ensure that only the interpreter thread gets used for any callbacks. That's probably fine as it is. Your patch attempts to initialize the thread as an MTA and drops to an STA in the event of a change-mode error. ActiveX controls tend to be STA requiring (Windows likes all GUI stuff to be done from one thread) so I would swap that around and try for a STA and then MTA. STA's are way more common particularly in GUI applications. I suspect that the problems you are having with the modified MTA tkvideo are to do with having a non-GUI thread making windoing calls or trying to paint the surface using the wrong thread. Something that is avoided by using an STA (and the reason ActiveX controls are usually apartment threaded). The real solution for all this would be to create a new thread for all the gstreamer stuff. If it wants to be MTA then it can do what it wants on its own thread. However that might not be that practical - I don't know how you use it. You could create a thread for all the tkvideo stuff too but in this case you want the functions that interact with the Tk window to be run from the GUI thread and that will require a significant rewrite I should think. >> Anyways, the problem with the 'devices' command is that the command returns >> TCL_ERROR but doesn't set the Tcl_Result, so we get the result that was >> previously set by the Tcl_GetIndexFromObjStruct in tkvideo.c (which only >> checks for cget, configure, xview and yview). >> I also noticed that commands like '$win start' also return this same result >> even if they succeed, because even if TCL_OK is returned, the Tcl_Result has >> not been modified... I suggest reseting the Tcl_Result before calling the >> subcommand's handler. OK This needs tidying up clearly. Pat Thoyts -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBSo/8S2B90JXwhOSJAQK5sAP9GFT1qtO2ywYK3p7weQaeJaaQM5EEsffQ sk4DQV2DDqTCa6qLgWw6qc4MqIZbteUOylP6nTS5Cp8lIFqehjD23VisjC4O62dU DQFJW6cYONWdRDnz0G8unMvnhPx5cUffz9k0bIpzAdIJ9ZlGKjD4JckJOqTCq/c4 IVBg7/d8DT0= =R8wq -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
