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
  1. Home
  2. Other Discussions
  3. The Weird and The Wonderful
  4. ThreadPool explosion

ThreadPool explosion

Scheduled Pinned Locked Moved The Weird and The Wonderful
architecture
6 Posts 4 Posters 0 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.
  • T Offline
    T Offline
    TheOnlyMaX
    wrote on last edited by
    #1

    Whereas the number of threads should be known in advance, the architecture of this application is so bad, that this check has been added before launching new threads, to avoid the ThreadPool to explode :

    var count = Process.GetCurrentProcess().Threads.Count;
    if (count > maxApplicationThreadCount) return;

    Cheers :cool:

    M B R 3 Replies Last reply
    0
    • T TheOnlyMaX

      Whereas the number of threads should be known in advance, the architecture of this application is so bad, that this check has been added before launching new threads, to avoid the ThreadPool to explode :

      var count = Process.GetCurrentProcess().Threads.Count;
      if (count > maxApplicationThreadCount) return;

      Cheers :cool:

      M Offline
      M Offline
      Marc Clifton
      wrote on last edited by
      #2

      Well, having a lot of threads isn't necessarily a bad thing. It depends on what they're doing. If they're sitting around waiting for some async process to complete, then should be OK. But if they're all competing for CPU time doing heavy processing, then yeah, that's not good. Marc

      Imperative to Functional Programming Succinctly

      1 Reply Last reply
      0
      • T TheOnlyMaX

        Whereas the number of threads should be known in advance, the architecture of this application is so bad, that this check has been added before launching new threads, to avoid the ThreadPool to explode :

        var count = Process.GetCurrentProcess().Threads.Count;
        if (count > maxApplicationThreadCount) return;

        Cheers :cool:

        B Offline
        B Offline
        Bernhard Hiller
        wrote on last edited by
        #3

        Also nice to note that it prevents the creation of new threads only after the maximum number has been exceeded...

        1 Reply Last reply
        0
        • T TheOnlyMaX

          Whereas the number of threads should be known in advance, the architecture of this application is so bad, that this check has been added before launching new threads, to avoid the ThreadPool to explode :

          var count = Process.GetCurrentProcess().Threads.Count;
          if (count > maxApplicationThreadCount) return;

          Cheers :cool:

          R Offline
          R Offline
          Rage
          wrote on last edited by
          #4

          ...which also implies that there is no feedback to the calling function whether the new thread has been started, or not. Interesting, at least. :)

          ~RaGE();

          I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Entropy isn't what it used to.

          T 1 Reply Last reply
          0
          • R Rage

            ...which also implies that there is no feedback to the calling function whether the new thread has been started, or not. Interesting, at least. :)

            ~RaGE();

            I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Entropy isn't what it used to.

            T Offline
            T Offline
            TheOnlyMaX
            wrote on last edited by
            #5

            Well, it's a timer (that is never stopped) that creates a worker thread in its callback method, so if there is too much threads, then... no work will be started. This check has been added because the duration of the worker thread was sometimes longer than the timer interval, so the number of threads was increasing indefinitely ! :wtf:

            R 1 Reply Last reply
            0
            • T TheOnlyMaX

              Well, it's a timer (that is never stopped) that creates a worker thread in its callback method, so if there is too much threads, then... no work will be started. This check has been added because the duration of the worker thread was sometimes longer than the timer interval, so the number of threads was increasing indefinitely ! :wtf:

              R Offline
              R Offline
              Rage
              wrote on last edited by
              #6

              If anything, this is a very good description on how we work here.

              ~RaGE();

              I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Entropy isn't what it used to.

              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