[webkit-dev] Thread naming policy in WebKit
Yusuke SUZUKI
utatane.tea at gmail.com
Thu Jan 5 12:34:12 PST 2017
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".
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/webkit-dev/attachments/20170106/d68eda42/attachment.html>
More information about the webkit-dev
mailing list