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

[Yusuke SUZUKI]

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/20170106/c9041506/attachment.html>