[jsc-dev] [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

Thank you for your suggestions!
Based on our discussion, I've uploaded the patch[1] :)

[1]: https://bugs.webkit.org/show_bug.cgi?id=166678

Regards,
Yusuke Suzuki

On Fri, Jan 6, 2017 at 2:50 PM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:

> On Fri, Jan 6, 2017 at 2:43 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
>>
>> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>>
>>> On Jan 5, 2017, at 9:37 AM, Brady Eidson <beidson at apple.com> wrote:
>>>
>>>
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI <utatane.tea at gmail.com>
>>> wrote:
>>>
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler <darin at apple.com> wrote:
>>>
>>>> I understand the appeal of “org.webkit” and structured names but
>>>> personally I would prefer to read names that look like titles and are made
>>>> up of words with spaces, like these:
>>>>
>>>> “WebKit: Image Decoder”, rather than “org.webkit.ImageDecoder”.
>>>> “WebKit: JavaScript DFG Compiler” rather than
>>>> “org.webkit.jsc.DFGCompiler”.
>>>>
>>>> Not sure how well that would generalize to all the different names.
>>>>
>>>> I like the idea of having a smart way of automatically making a shorter
>>>> name for the platforms that have shorter length limits.
>>>>
>>>
>>> One interesting idea I've come up with is that,
>>>
>>> 1. specifying "org.webkit.ImageDecoder"
>>> 2. In Linux, we just use "ImageDecoder" part.
>>> 3. In macOS port, we automatically convert it to "WebKit: Image Decoder”
>>>
>>>
>>> Why do we specify “org.webkit.ImageDecoder” if only the “ImageDecoder”
>>> part is ever going to be used?
>>> Is that because Windows could use “org.webkit.”?
>>>
>>>
>>> What about if you just specify "Image Decoder" and we automatically
>>> convert that to either "ImageDecoder" or "WebKit: Image Decoder" based on
>>> platform thread name limits? Is there any case where we want a prefix other
>>> than "WebKit: "?
>>>
>>
>> Yeah. For the prefix case, automatically adding "WebKit: " is fine. The
>> current ToT has the name like "com.apple.IPC.ReceiveQueue".
>> Previously I thought that we may need to convert it to "Apple WebKit:" or
>> something like that.
>> But now, I think simply using "WebKit: IPC Receive Queue" is fine.
>>
>> But I think automatically changing "ImageDecoder" to "Image Decoder" does
>> not work well with long names.
>> There is a name like "AsynchrnousDisassembler". It is >= 15 characters.
>> "AsynchronousDisas" is not good for Linux.
>> On the other hand, using "AsyncDisasm" => "WebKit: AsyncDisasm" is not
>> good for macOS.
>> For macOS, we can choose more readable name like "WebKIt: Asynchronous
>> Disassembler".
>>
>> So, I think Geoffrey's suggestion works well: using long / short name
>> pairs. Like,
>>
>> ThreadName { "Asynchronous Disassembler", "AsyncDisasm" } // { const
>> char*, const char* }
>>
>> // OR,
>> CREATE_THREAD_NAME("Asynchronous Disassembler", "AsyncDisasm") macro =>
>> generating ThreadName("WebKit: Asynchronous Disassembler") on macOS,
>> ThreadName("AsyncDisasm") on Linux
>>
>>
>> If there's a good set of "short name" and "long name" length limits, it
>> would be cool if we could check the length at compile time, which seems
>> more feasible with the macro.
>>
>>
> Yeah! That's what I would like to do. The typical ThreadName
> implementation would become the following.
>
> class ThreadName {
> public:
>     template<unsigned N>
>     explicit ThreadName(const char (&name)[N])
>         : m_name(name)
>     {
> #if OS(LINUX)
>         static_assert(N <= 16, "");
> #else if OS(WINDOWS)
>         static_assert(N <= 32, "");
> #endif
>     }
>
>     operator const char*()
>     {
>         return m_name;
>     }
>
> private:
>     const char* m_name;
> };
>
>
>
>> Regards,
>> Maciej
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/jsc-dev/attachments/20170109/86a0484b/attachment.html>