[webkit-dev] Thread naming policy in WebKit

[Filip Pizlo]

This sounds great to me!

-Filip

> On Jan 4, 2017, at 20:28, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
> 
> Hi WebKittens!
> 
> Recently, I started naming threads in Linux. And I also started naming threads created by WTF::AutomaticThread.
> Previously, all the thread is not named in Linux. It makes difficult to find problematic threads when using GDB in Linux.
> For example, if you run the JSC shell, all the threads are named as "jsc" (this is the name of the process).
> 
> The problem raised here is that we have no consistent policy for thread names.
> I picked several names in WebKit.
> 
> In WebCore,
>     IDB server is "IndexedDatabase Server"
>     AsyncAudioDecoder is "Audio Decoder"
>     GCController is "WebCore: GCController"
>     Icon Database is "WebCore: IconDatabase"
>     Audio's ReverbConvolver is "convolution background thread"
> The thread name used by WorkQueue in WebCore is,
>     Crypto Queue is "com.apple.WebKit.CryptoQueue"
>     Image decoder is "org.webkit.ImageDecoder"
>     Blob utility is "org.webkit.BlobUtility"
>     Data URL decoder is "org.webkit.DataURLDecoder"
> In JSC
>     Before this patch, all the AutomaticThreads (including JIT worklist / DFG worklist) is "WTF::AutomaticThread"
>     Super Sampler thread is "JSC Super Sampler"
>     Asychronous Disasm is "Asynchronous Disassembler"
>     Sampling profiler is "jsc.sampling-profiler.thread"
>     WASM compiler thread is "jsc.wasm-b3-compilation.thread"
> In WebKit2
>     Network Cache is "IOChannel::readSync"
>     IPC workqueue is "com.apple.IPC.ReceiveQueue"
> 
> To choose the appropriate naming policy, there are two requirements.
> This is discussed in https://bugs.webkit.org/show_bug.cgi?id=166678 and https://bugs.webkit.org/show_bug.cgi?id=166684
> 
> 1. We should have super descriptive name including the iformation "This thread is related to WebKit".
> If we use WebKit as the framework, WebKit will launch several threads along with the user application's threads.
> So if the thread name does not include the above information, it is quite confusing: Is this crash related to WebKit OR user's applications?
> This should be met at least in macOS port. In the Linux port, this requirement is a bit difficult to be met due to the second requirement.
> 
> 2. The thread name should be <= 15 characters in Linux. <= 31 characters in Windows.
> This is super unfortunate. But we need this requirement. But in macOS, I think we do not have any limitation like that (correct?)
> I cannot find "PTHREAD_MAX_NAMELEN_NP" definition in macOS.
> 
> To meet the above requirements as much as possible, I suggest the name, "org.webkit.MODULE.NAME(15characters)".
> This policy is derived from the WorkQueue's naming policy, like "org.webkit.ImageDecoder".
> For example, we will name DFG compiler worklist thread as "org.webkit.jsc.DFGCompiler" or "org.webkit.JavaScriptCore.DFGCompiler".
> 
> In Linux / Windows, we have the system to normalize the above name to "NAME(15characters)".
> For example, when you specify "org.webkit.jsc.DFGCompiler", it will be shown as "DFGCompiler" in Linux.
> This naming policy meets (1) in macOS. And (2) in all the environments. In macOS, the name is not modified.
> So we can see the full name "org.webkit.jsc.DFGCompiler".
> In Linux, we can see "DFGCompiler", it is quite useful compared to nameless threads.
> 
> What do you think of?
> 
> Best regards,
> Yusuke Suzuki
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170104/fb3049d0/attachment.html>