Re: [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  wrote:

> On Fri, Jan 6, 2017 at 2:43 PM, Maciej Stachowiak  wrote:
>
>>
>> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI  wrote:
>>
>> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak  wrote:
>>
>>>
>>> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
>>>
>>>
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI 
>>> wrote:
>>>
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  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
> 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
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

On Fri, Jan 6, 2017 at 2:43 PM, Maciej Stachowiak  wrote:

>
> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI  wrote:
>
> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak  wrote:
>
>>
>> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
>>
>>
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI  wrote:
>>
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  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
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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Maciej Stachowiak]

> On Jan 5, 2017, at 8:07 PM, Yusuke SUZUKI  wrote:
> 
> On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak  > wrote:
> 
>> On Jan 5, 2017, at 9:37 AM, Brady Eidson > > wrote:
>> 
>> 
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI >> > wrote:
>>> 
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler >> > 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.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

On Fri, Jan 6, 2017 at 10:37 AM, Maciej Stachowiak  wrote:

>
> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
>
>
> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI  wrote:
>
> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  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


>  - Maciej
>
>
> Again, back to Darin’s point, I don’t see any particular value in ever
> seeing “org.webkit.”
>
> Additionally, the way this proposal treats “ImageDecoder” as multiple
> words, presumably separated on case-change, is problematic.
>
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”,
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called,
> would expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
>
> —
>
> Taking your proposal and running with it, I think we could do this:
>
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…"
>
> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit:
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
>
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous
> Disassembler"
>
> Addendum: If we see value in having somethings flagged as “JSC” instead of
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific
> feature could be “WebKit. IndexedDB Server”
>
> Thanks,
> ~Brady
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Maciej Stachowiak]

> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
> 
> 
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI > > wrote:
>> 
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler > > 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: "?

 - Maciej

> 
> Again, back to Darin’s point, I don’t see any particular value in ever seeing 
> “org.webkit.”
> 
> Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
> presumably separated on case-change, is problematic.
> 
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called, would 
> expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
> 
> —
> 
> Taking your proposal and running with it, I think we could do this:
> 
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
> 
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…" 
> 
> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
> 
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous 
> Disassembler"
> 
> Addendum: If we see value in having somethings flagged as “JSC” instead of 
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
> feature could be “WebKit. IndexedDB Server”
> 
> Thanks,
> ~Brady
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

Regards,
Yusuke Suzuki

On Fri, Jan 6, 2017 at 5:34 AM, Yusuke SUZUKI  wrote:

> On Fri, Jan 6, 2017 at 2:37 AM, Brady Eidson  wrote:
>
>>
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI  wrote:
>>
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  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.”?
>>
>>
> Yup, we can drop this part. Originally, I was considering about 
> "com.apple.IPC.ReceiveQueue"
> in WebKit2 thread => "Apple WebKit: xxx".
> But I think just using "WebKit: " is OK.
>
>
>> Again, back to Darin’s point, I don’t see any particular value in ever
>> seeing “org.webkit.”
>>
>> Additionally, the way this proposal treats “ImageDecoder” as multiple
>> words, presumably separated on case-change, is problematic.
>>
>> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”,
>> different from today.
>> e.g. “IndexedDBServer”, which is probably what this should be called,
>> would expand to “Indexed D B Server"
>> e.g. “GCController” would expand to “G C Controller”
>>
>
> If we recognize the [UpperCharacter]*[LowerCharacter]* as word, we can
> split it as "GC Controller".
>

Oops, I mean using ([UpperCharacter][LowerCharacter]) to split the word.


> But anyway, it causes a problem when we encounter a name like
> "XMLDBController".
>
>
>>
>> —
>>
>> Taking your proposal and running with it, I think we could do this:
>>
>> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>>
>> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
>> 2a - It could get truncated with ellipses: “AsynchronousDi…"
>>
>
> I think we should not truncate the name for Linux.
> My automatic shortening is based on the fact that "org.webkit.MODULE.NAME"'s
> NAME part is always <= 15 characters. So we do not truncate.
>
> But if we have names like "Asynchronous Indexed Database Server" and
> "Asynchronous Indexed Database Client", the both become "AsynchronousIndex"
> in Linux.
> It is not helpful.
>
> However always using 15 characters names effectively limits the ability of
> macOS's thread names.
>
> So now, I like Geoff's idea, having 2 names, long name and short name.
> For example, we have "Asynchronous Disassembler" and "AsyncDisasm".
> Then, in macOS, use "WebKit: Asynchronous Disassembler".
> In Windows, use "WebKit: AsyncDisasm".
> In Linux, use "AsyncDisasm".
>
>
>> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit:
>> Asynchronous Disassemb”
>> 3a - It could get truncated with ellipses: “WebKit: Asynchronous
>> Disassem…”
>>
>> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous
>> Disassembler"
>>
>> Addendum: If we see value in having somethings flagged as “JSC” instead
>> of “WebKit”, we just augment the input to include that.
>> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific
>> feature could be “WebKit. IndexedDB Server”
>>
>
> Yeah, we can add JSC prefix in long name part if we want.
>
>
>>
>> Thanks,
>> ~Brady
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

On Fri, Jan 6, 2017 at 2:37 AM, Brady Eidson  wrote:

>
> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI  wrote:
>
> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  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.”?
>
>
Yup, we can drop this part. Originally, I was considering about
"com.apple.IPC.ReceiveQueue"
in WebKit2 thread => "Apple WebKit: xxx".
But I think just using "WebKit: " is OK.


> Again, back to Darin’s point, I don’t see any particular value in ever
> seeing “org.webkit.”
>
> Additionally, the way this proposal treats “ImageDecoder” as multiple
> words, presumably separated on case-change, is problematic.
>
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”,
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called,
> would expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
>

If we recognize the [UpperCharacter]*[LowerCharacter]* as word, we can
split it as "GC Controller".
But anyway, it causes a problem when we encounter a name like
"XMLDBController".


>
> —
>
> Taking your proposal and running with it, I think we could do this:
>
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…"
>

I think we should not truncate the name for Linux.
My automatic shortening is based on the fact that "org.webkit.MODULE.NAME"'s
NAME part is always <= 15 characters. So we do not truncate.

But if we have names like "Asynchronous Indexed Database Server" and
"Asynchronous Indexed Database Client", the both become "AsynchronousIndex"
in Linux.
It is not helpful.

However always using 15 characters names effectively limits the ability of
macOS's thread names.

So now, I like Geoff's idea, having 2 names, long name and short name.
For example, we have "Asynchronous Disassembler" and "AsyncDisasm".
Then, in macOS, use "WebKit: Asynchronous Disassembler".
In Windows, use "WebKit: AsyncDisasm".
In Linux, use "AsyncDisasm".


> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit:
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
>
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous
> Disassembler"
>
> Addendum: If we see value in having somethings flagged as “JSC” instead of
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific
> feature could be “WebKit. IndexedDB Server”
>

Yeah, we can add JSC prefix in long name part if we want.


>
> Thanks,
> ~Brady
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Filip Pizlo]

👍

-Filip


> On Jan 5, 2017, at 10:51 AM, Geoffrey Garen  wrote:
> 
> Alternatively, we could just change thread name from a char* to a struct { 
> char*, char* } that contains a long name and a short name.
> 
> Geoff
> 
>> On Jan 5, 2017, at 9:37 AM, Brady Eidson > > wrote:
>> 
>>> 
>>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI >> > wrote:
>>> 
>>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler >> > 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.”?
>> 
>> Again, back to Darin’s point, I don’t see any particular value in ever 
>> seeing “org.webkit.”
>> 
>> Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
>> presumably separated on case-change, is problematic.
>> 
>> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
>> different from today.
>> e.g. “IndexedDBServer”, which is probably what this should be called, would 
>> expand to “Indexed D B Server"
>> e.g. “GCController” would expand to “G C Controller”
>> 
>> —
>> 
>> Taking your proposal and running with it, I think we could do this:
>> 
>> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
>> 
>> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
>> 2a - It could get truncated with ellipses: “AsynchronousDi…" 
>> 
>> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
>> Asynchronous Disassemb”
>> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
>> 
>> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous 
>> Disassembler"
>> 
>> Addendum: If we see value in having somethings flagged as “JSC” instead of 
>> “WebKit”, we just augment the input to include that.
>> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
>> feature could be “WebKit. IndexedDB Server”
>> 
>> Thanks,
>> ~Brady
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Geoffrey Garen]

Alternatively, we could just change thread name from a char* to a struct { 
char*, char* } that contains a long name and a short name.

Geoff

> On Jan 5, 2017, at 9:37 AM, Brady Eidson  wrote:
> 
>> 
>> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI > > wrote:
>> 
>> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler > > 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.”?
> 
> Again, back to Darin’s point, I don’t see any particular value in ever seeing 
> “org.webkit.”
> 
> Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
> presumably separated on case-change, is problematic.
> 
> e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
> different from today.
> e.g. “IndexedDBServer”, which is probably what this should be called, would 
> expand to “Indexed D B Server"
> e.g. “GCController” would expand to “G C Controller”
> 
> —
> 
> Taking your proposal and running with it, I think we could do this:
> 
> 1 - Specify the feature name with spaces: “Asynchronous Disassembler”
> 
> 2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
> 2a - It could get truncated with ellipses: “AsynchronousDi…" 
> 
> 3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
> Asynchronous Disassemb”
> 3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”
> 
> 4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous 
> Disassembler"
> 
> Addendum: If we see value in having somethings flagged as “JSC” instead of 
> “WebKit”, we just augment the input to include that.
> The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
> feature could be “WebKit. IndexedDB Server”
> 
> Thanks,
> ~Brady
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Brady Eidson]

> On Jan 5, 2017, at 12:48 AM, Yusuke SUZUKI  wrote:
> 
> On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  > 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.”?

Again, back to Darin’s point, I don’t see any particular value in ever seeing 
“org.webkit.”

Additionally, the way this proposal treats “ImageDecoder” as multiple words, 
presumably separated on case-change, is problematic.

e.g. “IndexedDatabaseServer” would expand to “Indexed Database Server”, 
different from today.
e.g. “IndexedDBServer”, which is probably what this should be called, would 
expand to “Indexed D B Server"
e.g. “GCController” would expand to “G C Controller”

—

Taking your proposal and running with it, I think we could do this:

1 - Specify the feature name with spaces: “Asynchronous Disassembler”

2 - On Linux, it gets collapsed and truncated to 15: “AsynchronousDis”
2a - It could get truncated with ellipses: “AsynchronousDi…" 

3 - On Windows, it gets “WebKit: “ added and is truncated to 30: “WebKit: 
Asynchronous Disassemb”
3a - It could get truncated with ellipses: “WebKit: Asynchronous Disassem…”

4 - On macOS/iOS, it gets “WebKit: “ added: “WebKit: Asynchronous Disassembler"

Addendum: If we see value in having somethings flagged as “JSC” instead of 
“WebKit”, we just augment the input to include that.
The above could be “JSC.Asynchronous Disassembler”, and a WebKit specific 
feature could be “WebKit. IndexedDB Server”

Thanks,
~Brady___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Brady Eidson]

> On Jan 5, 2017, at 12:43 AM, Darin Adler  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”.

I strongly agree with this.

That is, I strongly disagree with having to see “org.webkit.FOO” on macOS/iOS.

> 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.

This seems good and possible.

Thanks,
~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Michael Catanzaro]

On Thu, 2017-01-05 at 17:48 +0900, Yusuke SUZUKI wrote:
> 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"

This sounds like a good path forward that works for all platforms.

It's a shame that low platform limits have made this unnecessarily
complicated. Traditionally, Linux folks shame older UNIXes for having
such low limits; it's interesting to be on the other end of this
now

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

On Thu, Jan 5, 2017 at 5:43 PM, Darin Adler  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"


>
> — Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Darin Adler]

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.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thread naming policy in WebKit

[Filip Pizlo]

This sounds great to me!

-Filip

> On Jan 4, 2017, at 20:28, Yusuke SUZUKI  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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Thread naming policy in WebKit

[Yusuke SUZUKI]

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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev