Understanding Multi-Threading in VB.Net - Page 4-VBForums
Page 4 of 4 FirstFirst 1234
Results 121 to 126 of 126

Thread: Understanding Multi-Threading in VB.Net

  1. #121
    Junior Member
    Join Date
    Jul 2012
    Posts
    21

    Re: Understanding Multi-Threading in VB.Net

    Hi, just wanted to ask something, if we start an app, and in the app start a thread, and then we close the app, will the thread also close or will it continue until it's done with what it had to do?

  2. #122
    Frenzied Member
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    1,257

    Re: Understanding Multi-Threading in VB.Net

    It depends on if the thread is a Background thread (it will end when the main thread, aka the GUI thread in a winforms application ends) or not.
    If it is not a background thread, it will continue to run until it finishes.
    <edit> Just realized that this in the CodeBank forum. You should post questions like these in a new thread, rather than in a CodeBank thread. </edit>

  3. #123
    New Member
    Join Date
    Dec 2014
    Posts
    3

    Re: Understanding Multi-Threading in VB.Net

    It will continue, you can test this by (while debug mode) creating and starting a new thread with an infinite loop and closing the app. Now if you look at your controls inf Visual Studio you will see that the START button is disabled and the STOP button is enabled even though your app should be done.

  4. #124
    New Member
    Join Date
    Dec 2014
    Posts
    3

    Re: Understanding Multi-Threading in VB.Net

    This thread is ancient but it still seams to get some interest. If you guys are interested I created a jump-start Video Tutorial on Multi-Threading. It's on YouTube http://www.youtube.com/playlist?list...3Sfvzlsha4Jdnk

  5. #125

    Thread Starter
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,006

    Re: Understanding Multi-Threading in VB.Net

    Quote Originally Posted by walterwjl View Post
    Hi, just wanted to ask something, if we start an app, and in the app start a thread, and then we close the app, will the thread also close or will it continue until it's done with what it had to do?
    Quote Originally Posted by Irek Janek View Post
    It will continue, you can test this by (while debug mode) creating and starting a new thread with an infinite loop and closing the app. Now if you look at your controls inf Visual Studio you will see that the START button is disabled and the STOP button is enabled even though your app should be done.
    As passel said, it depends on if the thread in question is a background thread. I explained in the tutorial that an application stops only when all foreground threads are stopped. When all foreground threads are stopped then all background threads will also be terminated and no infinite loop will prevent this.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

  6. #126

    Thread Starter
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    5,006

    Re: Understanding Multi-Threading in VB.Net

    Quote Originally Posted by StatShacker View Post
    Niya,
    At this point I don't suppose you ~need~ to hear again what an outstanding job you've done here but I think you should here it!!! And like several others, your posts and in particular your responses to the replies of others inspired me to register here just to tell you how much I appreciate how cogent your instructions are, how patient you are in your responses to nuubs (myself included hopefully), how generous you are of your time to continue supporting this thread now for over almost two and a half years and (he bows his head in embarrassment) to ask a few questions of my own.
    Notwithstanding my questions, my inspiration to register came from my need to tell you that you are truly the "Angel of Code," for this is, by far, the best thread on multi-threading (sorry for the pun) that I've found and I am certain not to find one better. What has made this thread even better are some of the queries to it and your thoughtful, helpful and instructive responses to them. I hope that (even as a nuub) my questions can make a contribution in this realm.
    Nice to hear this has been helpful.

    Quote Originally Posted by StatShacker View Post
    Question 1) Please confirm. (my situation) If you have a third party component instantiated in the main thread; when you handle a callback from that component, the callback is directly run in the main UI thread, if the callback delegate and method are in the code for the main form, yes? I am pretty sure the answer is 'Yes,' but I'm not 100% sure that the code in the component (clearly a separate thread) extend itself into the callback method...
    I think you may be holding onto a few misconceptions. Firstly, objects aren't really thread specific in the strictest technical terms. While some classes might goad you into paying attention to the thread they were created on, know that there is nothing inherent in the operation of the .Net Framework that says that an object belongs to a particular thread. This is all the work of the person who wrote the class. They can choose to have that class execute its methods on that thread or to have them executed on only the UI thread regardless of where it was created.

    Executing methods are thread specific, not the classes that define them. That being said, you can never make assumptions about what thread a callback will be executed on. The only way to be certain is to consult the documentation for the component. A properly documented component will inform you how their callbacks are executed. However, there are common patterns surrounding callbacks that can help you make a well informed guess. One such pattern is the asynchronous pattern which you might have seen on classes like the Socket class. The Socket class has several methods which have asynchronous variants. In those cases, callbacks are employed to signal either the failure or success of an operation. These callbacks are usually executed on a worker thread. If you see a pattern like that, you can make a well informed guess. But its still not a guarantee.


    Quote Originally Posted by StatShacker View Post
    Question 2) Please confirm. Some of your responses to queries were (understandably) VB.Net Framework version dependent . With the final version of your post (i.e., using the "QueueUserWorkItem" of ThreadPool, which works under Framework 3.5, my target), is it necessary to "EndInvoke" this thread? Again I'm pretty sure, based on reading descriptions written elsewhere about ThreadPool, but ask so I can sleep at night with no lingering doubts...
    No, you don't need to call and type of 'EndInvoke' method for QueueUserWorkItem. EndInvoke is usually employed with the asynchronous pattern I mentioned above.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena


    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. -jmcilhinney

Page 4 of 4 FirstFirst 1234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.