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

[Yusuke SUZUKI]

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


>  - 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 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/jsc-dev/attachments/20170106/d8470e73/attachment.html>