Traceline is a good way to see how this happens. We generally name all of the Chrome threads (base::Thread), but the system is allowed to create threads of its own. Loads of APIs create threads, along with the windows worker pool (which we make good use of to help reuse threads). For example, wininet can create it's own thread pools, etc. I did some work on cutting down the number of threads and thread creation times. In specific thread creation can contend the main UI thread because of holding the loader lock for DLLMain initialization, etc.
Here is an older example of traceline output: http://deanm.github.com/misc/traceline/traceline.xml#startup-release.json You can easily see which threads are created, when, and the call stacks for what created them by hovering on the lines. -- dean On Thu, Dec 31, 2009 at 7:09 PM, Jim Roskind <j...@chromium.org> wrote: > I'm pretty sure we name all the threads we can (or at least used to), I > *think* the problem is worker threads in a thread pool, which are started up > and shut down automatically, and aren't named (and don't have message > loops). > When I was doing the work to generate the internal page about:tasks, it was > critical to have names on all the threads (that I could), as the data also > shows what threads sent and received tasks. > Jim > On Thu, Dec 31, 2009 at 1:11 AM, Berend-Jan Wever <skyli...@chromium.org> > wrote: >> >> If you do not care about the way threads are run inside a process in >> Chromium, you can stop reading now. >> Some of our threads are named, while others are not. See below cdb.exe >> output for a renderer process: >> >> 2:020:x86> ~ >> 1 Id: d98.1588 Suspend: 1 Teb: 7efd8000 Unfrozen >> "Chrome_ChildIOThread" >> . 20 Id: d98.1440 Suspend: 1 Teb: 7efdb000 Unfrozen "Main Thread" >> 21 Id: d98.10d4 Suspend: 1 Teb: 7ef4d000 Unfrozen >> 22 Id: d98.171c Suspend: 1 Teb: 7efd5000 Unfrozen >> 2:020:x86> ~21 s >> ntdll32!ZwWaitForMultipleObjects+0x15: >> 76fa99fd c21400 ret 14h >> 2:021:x86> kp >> ChildEBP RetAddr >> 0399fcd4 7702787d ntdll32!ZwWaitForMultipleObjects+0x15 >> 0399fe68 750feccb ntdll32!TppWaiterpThread+0x328 >> 0399fe74 76fdd24d kernel32!BaseThreadInitThunk+0xe >> 0399feb4 76fdd45f ntdll32!__RtlUserThreadStart+0x23 >> 0399fecc 00000000 ntdll32!_RtlUserThreadStart+0x1b >> 2:021:x86> ~22 s >> ntdll32!NtWaitForWorkViaWorkerFactory+0x12: >> 76fab5ee c20800 ret 8 >> 2:022:x86> kp >> ChildEBP RetAddr >> 0357f6ec 76f9b927 ntdll32!NtWaitForWorkViaWorkerFactory+0x12 >> 0357f81c 750feccb ntdll32!TppWorkerThread+0x1f6 >> 0357f828 76fdd24d kernel32!BaseThreadInitThunk+0xe >> 0357f868 76fdd45f ntdll32!__RtlUserThreadStart+0x23 >> 0357f880 00000000 ntdll32!_RtlUserThreadStart+0x1b >> >> What are these threads and why are they nameless? Did we create these >> threads at all? (They could have been created by plugins/detours/etc. that >> we have no control over.) >> It would be nice if we could name all threads, so you know what you're >> looking at. >> Thanks! >> BJ >> >> Berend-Jan "SkyLined" Wever <skyli...@google.com> >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
