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

[Yusuke SUZUKI]

Regards,
Yusuke Suzuki

On Fri, Jan 6, 2017 at 5:34 AM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:

> On Fri, Jan 6, 2017 at 2: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.”?
>>
>>
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/jsc-dev/attachments/20170106/1e7ec949/attachment.html>