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