 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / July 2007System.Diagnostics.StackTrace future ?
The constructor new System.Diagnostics.StackTrace(System.Threading.Thread targetThread, bool getSourceInformation) *requires* that the target thread be suspended. But System.Threading.Thread.Suspend (and .Resume) are currently labelled Obsolete and the documentation states that they are scheduled to be removed in a future version. What is planned to avoid the upcoming uselessness of this StackTrace ctor? Our suggestion would be another signature for the StackTrace constructor which takes a boolean flag indicating that you want the stack trace even if the thread is not suspended (implemented however they want, maybe by suspending the thread internally). All you are assured is that the returned stack trace was a true stack trace for the target thread *sometime* during the StackTrace ctor call. We are using this feature to perform statistical execution profiling of a thread from within the application itself (using another thread of course). Hi Keith, From your description, you're looking for the recommended means to capture stacktrace from a given thread (by using the StackTrace class) since the Thread.Suspend/Resume methods are obsolete in .net framework 2.0, correct? I've checked the document and it seem the obsolete of the Thread's "Suspend/Resume" methods does cause the StackTrace's constuctor with a given thread not work. Currently, I'll perform some further research and look for some further resource on this to see whether we have any other alternative means. I'll update you as soon as I get any new information. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. That is what we are looking to do and wanted to know what direction the future holds... Thanks. > Hi Keith, > [quoted text clipped - 40 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Hi Keith, Yes, I'm also interested in this issue and currently also involving some other framework engineers to discuss on this. I'll keep you update. Thanks for your understanding. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. Hi Keith, Just add a message you let you know that I'm still contacting some other engineers on this issue and keep focus on this. I'll update you as soon as possible. Thanks for your understanding! Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. Hi Keith, I've just got some further information on this problem. Here are some comments from our dev team engineers: <<<<<<<<<<<<<<<<<<<<<<<<<<<<< So far there's no safe way to do this - you have to suspend the thread, and suspending the thread is an unsafe operation. It might get suspended somewhere while it holds a particularly dangerous lock. When you try and walk the stack you might need that lock and you'll hit a deadlock. The only safe way would be to have the thread cooperate and grab its own stack trace and hand it off to you. Or if you're just doing this for diagnostic purposes you could suppress the warning on calling the obsolete method and do it anyway - just make sure to cross your fingers and avoid black cats, don't break any mirrors, etc¡ In addition, I also recommend send this feedback to our product feedback center(connect site): http://connect.microsoft.com/feedback/default.aspx?SiteID=210 thus, our dev team can also get informed on this feedback. Thank you for your understanding! Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. Hi Keith, Do you have any further concerns on this or if you have any other questions need help, please feel free to post here. Sincerely, Steven Cheng Microsoft MSDN Online Support Lead This posting is provided "AS IS" with no warranties, and confers no rights. I went to post on the connect.live site, and discovered someone else had posted almost the exact same thing. I added our comments to that thread. Thanks, Keith > Hi Keith, > [quoted text clipped - 8 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.