Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor
  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C#
  4. Long operation in c#, when does main end?

Long operation in c#, when does main end?

Scheduled Pinned Locked Moved C#
csharpmobilehelpquestion
20 Posts 9 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Luc Pattyn

    Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

    Luc Pattyn

    Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

    Local announcement (Antwerp region): Lange Wapper? Neen!

    N Offline
    N Offline
    Nagy Vilmos
    wrote on last edited by
    #3

    Is that one of your 'out of the box' answers or did you actually compose it? Very good whichever way.

    Panic, Chaos, Destruction. My work here is done.

    L 1 Reply Last reply
    0
    • L Luc Pattyn

      Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

      Luc Pattyn

      Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

      Local announcement (Antwerp region): Lange Wapper? Neen!

      M Offline
      M Offline
      musefan
      wrote on last edited by
      #4

      I did actually start writing a response but I cancelled it with the thought that you would inevitably provide a better answer... and right I was ;)

      Life goes very fast. Tomorrow, today is already yesterday.

      L 1 Reply Last reply
      0
      • L Luc Pattyn

        Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

        Luc Pattyn

        Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

        Local announcement (Antwerp region): Lange Wapper? Neen!

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #5

        Nice! 5

        1 Reply Last reply
        0
        • L Luc Pattyn

          Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

          Luc Pattyn

          Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

          Local announcement (Antwerp region): Lange Wapper? Neen!

          N Offline
          N Offline
          Nuri Ismail
          wrote on last edited by
          #6

          Wooow!!! Very good answer! :thumbsup: :)

          1 Reply Last reply
          0
          • N Nagy Vilmos

            Is that one of your 'out of the box' answers or did you actually compose it? Very good whichever way.

            Panic, Chaos, Destruction. My work here is done.

            L Offline
            L Offline
            Luc Pattyn
            wrote on last edited by
            #7

            that was an instantaneous composition, but I might add it to my collection of standard replies. Good suggestion. :)

            Luc Pattyn

            Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

            Local announcement (Antwerp region): Lange Wapper? Neen!

            1 Reply Last reply
            0
            • M musefan

              I did actually start writing a response but I cancelled it with the thought that you would inevitably provide a better answer... and right I was ;)

              Life goes very fast. Tomorrow, today is already yesterday.

              L Offline
              L Offline
              Luc Pattyn
              wrote on last edited by
              #8

              musefan wrote:

              inevitably

              You shouldn't give in so easily; I might be absent, late or completely wrong. :-D

              Luc Pattyn

              Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

              Local announcement (Antwerp region): Lange Wapper? Neen!

              M 1 Reply Last reply
              0
              • L Luc Pattyn

                Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

                Luc Pattyn

                Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                Local announcement (Antwerp region): Lange Wapper? Neen!

                Y Offline
                Y Offline
                yeah1000
                wrote on last edited by
                #9

                Good one indeed, thank you :)

                1 Reply Last reply
                0
                • L Luc Pattyn

                  musefan wrote:

                  inevitably

                  You shouldn't give in so easily; I might be absent, late or completely wrong. :-D

                  Luc Pattyn

                  Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                  Local announcement (Antwerp region): Lange Wapper? Neen!

                  M Offline
                  M Offline
                  musefan
                  wrote on last edited by
                  #10

                  Maybe... but I think you will still be posting here long after your dead, and with the same quality as always :)

                  Life goes very fast. Tomorrow, today is already yesterday.

                  L 1 Reply Last reply
                  0
                  • M musefan

                    Maybe... but I think you will still be posting here long after your dead, and with the same quality as always :)

                    Life goes very fast. Tomorrow, today is already yesterday.

                    L Offline
                    L Offline
                    Luc Pattyn
                    wrote on last edited by
                    #11

                    You may be right there. My bot seems to be passing the Turing test quite well. :)

                    Luc Pattyn

                    Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                    Local announcement (Antwerp region): Lange Wapper? Neen!

                    M 1 Reply Last reply
                    0
                    • L Luc Pattyn

                      Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

                      Luc Pattyn

                      Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                      Local announcement (Antwerp region): Lange Wapper? Neen!

                      D Offline
                      D Offline
                      dan sh
                      wrote on last edited by
                      #12

                      Great explanation. MVP status justified (yet again) :thumbsup: Whenever you write a book or you already have, just inform us. I will surely buy one.

                      It's not necessary to be so stupid, either, but people manage it. - Christian Graus, 2009 AD

                      M L 3 Replies Last reply
                      0
                      • L Luc Pattyn

                        You may be right there. My bot seems to be passing the Turing test quite well. :)

                        Luc Pattyn

                        Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                        Local announcement (Antwerp region): Lange Wapper? Neen!

                        M Offline
                        M Offline
                        musefan
                        wrote on last edited by
                        #13

                        :) mine is useless, it remembers things but its understanding of sentences is very limited

                        Life goes very fast. Tomorrow, today is already yesterday.

                        1 Reply Last reply
                        0
                        • D dan sh

                          Great explanation. MVP status justified (yet again) :thumbsup: Whenever you write a book or you already have, just inform us. I will surely buy one.

                          It's not necessary to be so stupid, either, but people manage it. - Christian Graus, 2009 AD

                          M Offline
                          M Offline
                          musefan
                          wrote on last edited by
                          #14

                          Indeed, I would too be very interested in a book from Luc

                          Life goes very fast. Tomorrow, today is already yesterday.

                          1 Reply Last reply
                          0
                          • D dan sh

                            Great explanation. MVP status justified (yet again) :thumbsup: Whenever you write a book or you already have, just inform us. I will surely buy one.

                            It's not necessary to be so stupid, either, but people manage it. - Christian Graus, 2009 AD

                            L Offline
                            L Offline
                            Luc Pattyn
                            wrote on last edited by
                            #15

                            Thank you. I haven't written a book yet, and I don't plan to. I did collect a lot of good answers (others and mine) to many questions, all in all some 100 pages in Word right now. Occasionally I turn some of it into a little article[^]. :)

                            Luc Pattyn

                            Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                            Local announcement (Antwerp region): Lange Wapper? Neen!

                            1 Reply Last reply
                            0
                            • L Luc Pattyn

                              Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

                              Luc Pattyn

                              Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                              Local announcement (Antwerp region): Lange Wapper? Neen!

                              N Offline
                              N Offline
                              N a v a n e e t h
                              wrote on last edited by
                              #16

                              Luc Pattyn wrote:

                              With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time).

                              In case you are wondering why DoEvents is bad: It is because DoEvents can lead to method reentrancy issues. Good post though :thumbsup:

                              Navaneeth How to use google | Ask smart questions

                              L 1 Reply Last reply
                              0
                              • D dan sh

                                Great explanation. MVP status justified (yet again) :thumbsup: Whenever you write a book or you already have, just inform us. I will surely buy one.

                                It's not necessary to be so stupid, either, but people manage it. - Christian Graus, 2009 AD

                                L Offline
                                L Offline
                                Luc Pattyn
                                wrote on last edited by
                                #17

                                Forgot some: - I did create a couple of in-house courses, the most elaborate one was on Java (more than 10 years ago) when we decided to move an entire team from C to Java; - and I did start two manuscripts that each might become a book one day, one on software performance, and one on software debugging. But I wouldn't hold my breath, progress is minimal. :)

                                Luc Pattyn

                                Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                                Local announcement (Antwerp region): Lange Wapper? Neen!

                                1 Reply Last reply
                                0
                                • N N a v a n e e t h

                                  Luc Pattyn wrote:

                                  With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time).

                                  In case you are wondering why DoEvents is bad: It is because DoEvents can lead to method reentrancy issues. Good post though :thumbsup:

                                  Navaneeth How to use google | Ask smart questions

                                  L Offline
                                  L Offline
                                  Luc Pattyn
                                  wrote on last edited by
                                  #18

                                  Right. If you're lucky, you run out of stack right away; if unlucky, you'll notice something is wrong after deployment. :)

                                  Luc Pattyn

                                  Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                                  Local announcement (Antwerp region): Lange Wapper? Neen!

                                  1 Reply Last reply
                                  0
                                  • Y yeah1000

                                    Hi, my problem is the following: I wrote a program that downloads lots of images from the internet (not porn though :P). Anywhoo, when i had the entire program in one thread it was not very responsive during the downloading (i used application.doevents in between the downloading cycles). When i added a separate thread for the downloading part i could move the windows around on the screen quickly and with no problems. What i don't quite understand is the why. What controls the movement of the program window during execution? Does the main thread decide how much processor time it gives for the program and how much for the movement? When does the main thread end? Does it ever end, due to the fact that it has to handle button clicks? Does main thread end when there are multiple threads? If it does end before the downloading thread, how can the smooth window movement during downloading be explained (as there is still only one thread running?). TY

                                    N Offline
                                    N Offline
                                    N a v a n e e t h
                                    wrote on last edited by
                                    #19

                                    Another important thing to consider when working with a multi-threaded application is to safely end all worker threads when application is closing. Your application won't quit completely when there are active worker threads. One easy way to do this is to use background threads(Thread.IsBackGround = true). Background threads will be aborted automatically when the main thread exits and application will quit smoothly. My 2 cents :)

                                    Navaneeth How to use google | Ask smart questions

                                    1 Reply Last reply
                                    0
                                    • L Luc Pattyn

                                      Hi, when your app starts, it has only one thread, the "main" or "GUI" thread. It gets more if and when you create them (Thread, ThreadPool, BackgroundWorker) or perform asynchronous I/O operations (e.g. SerialPort.DataReceived). All GUI operations (including window moving and resizing) are handled on the main thread; that mainly consists of executing the event handlers you provide, such as Form_Load, Button_Click, and many others. The events that trigger them are collected in an "input queue" and executed one by one, so one handler has to finish before the next one can start; that is why a window won't move if it is in the middle of a lengthy operation inside say a Button_Click handler. With one exception: when Application.DoEvents() is called often enough, everything may appear to be running smoothly (in reality you are running a big risk of instability, one should avoid DoEvents most of the time). To keep the GUI responsive one should limit the execution time of each handler to a small timespan, say 30 milliseconds. Anything that always or sometimes may take more should be delegated to another thtead; otherwise the user will dislike the way he looses control of the GUI. And the main thread comes to an end when it has no more work to execute, that typically happens when the main form gets closed causing the Application.Run() method to return in the static Main() method (inside file Program.cs); unless you started some threads that still haven't finished executing their code and didn't get marked with IsBackground=true. :)

                                      Luc Pattyn

                                      Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

                                      Local announcement (Antwerp region): Lange Wapper? Neen!

                                      D Offline
                                      D Offline
                                      DaveyM69
                                      wrote on last edited by
                                      #20

                                      Great answer Luc :thumbsup:

                                      Dave
                                      Generic BackgroundWorker - My latest article!
                                      BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
                                      Why are you using VB6? Do you hate yourself? (Christian Graus)

                                      1 Reply Last reply
                                      0
                                      Reply
                                      • Reply as topic
                                      Log in to reply
                                      • Oldest to Newest
                                      • Newest to Oldest
                                      • Most Votes

                                      • Login
                                      • Don't have an account? Register
                                      • Login or register to search.
                                      • First post
                                        Last post
                                      0
                                      • Categories
                                      • Recent
                                      • Tags
                                      • Popular
                                      • World
                                      • Users
                                      • Groups