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