The product is required to support application sessions, so there will be contention for ui services from the session threads, but my primary concern at the moment is wrt startup of the main app form and the session listener thread which spawns a subsequent modeless form.
Sessions will be activated by events from hardware devices eg card readers, which are sent to the listener, so the ui does not neccesarily drive the requests for the ui services. I've used ADPlus to gen the following report on the UI thread (a34)... . 0 Id: 978.a34 Suspend: 1 Teb: 7ffde000 Unfrozen *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINNT\system32\ntdll.dll - ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 04b22848 000003c1 000002f2 00000000 0013dd80 USER32!UpdateWindow+0x3d Note that this hang dump gets produced after the listener thread has been spawned and used the UiSync object to launch a modeless form - but before the next invoke which disappears into never never land. regards -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of Toby Selwood Sent: 12 April 2005 16:28 To: [email protected] Subject: Re: [ADVANCED-DOTNET] UI thread problems Does the UI thread ever wait for any locks? Is it possible it's waiting for the background thread to release some resource? Tobias Selwood ----- Original Message ----- From: "Ross Diesel" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, April 12, 2005 8:32 AM Subject: [ADVANCED-DOTNET] UI thread problems > Hi > > I'm struggling with what appears to be deadlock/UI thread marshall > failure. > > The main application thread creates a UI synchronization object (UiSync) > on > startup and thereafter spawns a background thread (listener - not a pooled > thread) which is given access to UiSync. > > UiSync supports ISynchronizeInvoke by inheriting from > System.Windows.Forms.Form. > > The background thread uses the UiSync object to create and launch a > modeless > form. In the case of our product though, both the main form and the newly > launched form cease to respond to user input. In various other test > harnesses both the test harness application form and the UiSync launched > form remain responsive to user input. In the case of product the listener > thread remains responsive to message queue receives. > > Further, in the case of our product, we are spawning session threads from > our background thread on receipt of certain messages. These session > threads > are responsable for invoking UI functionality (web browser control > creation > and parenting) using the UiSync object. When the backgrond thread receives > and processes the first start session request, the UiSync.Invoke is > executed > and the application deadlocks and all ui is frozen. > > I have developed a number of test harness varying in complexity (wrt the > background processing) but these test harnesses all fail to reproduce the > deadlock/marshalling problem in our product when UiSync.Invoke is > executed. > UiSync.InvokeRequired is checked (and returns true) prior to execution of > the Invoke in the test harnesses and the product. > > Pausing the VS debugger and examining the process threads provides no > thread > status clues. > > Any suggestions as to the probable cause or to more sophisticated > tools/techniques for debugging this kind of problem would be most > appreciated. > > regards > > =================================== > This list is hosted by DevelopMentor� http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
