adding logging for thread-related stuff (Unified Logging)

[David Holmes]

Hi Thomas,

Haven't had time to look at this yet sorry. Just wanted you to know it 
isn't being ignored. :)

Thanks,
David

On 5/12/2015 8:29 PM, Thomas Stüfe wrote:
> Hi all,
>
> I would like to add tracing to trace things around threads, from the OS
> point of view:
> - trace thread starts and finish, incl. pthread id, kernel thread id...
> - trace stack locations
> - trace guard page locations and when they are protected, unprotected
> - ...
>
> In the future there may be more OS related stuff to trace, like signal
> handling etc.
>
> This is mainly motivated by the AIX port (see e.g.
> https://bugs.openjdk.java.net/browse/JDK-8144343?filter=22798), but I would
> like to add this for all platforms. So, I have some questions:
>
> 1) are there any objections?
>
> 2) if not, how should I name the tag? "os"? "os-threads"? "threads"? I
> would like to use "os" as "anything at the VM-OS border".
>
> 3) for errno values: I have never been happy with strerror(). I propose to
> add a function which returns the name of the errno enum for the value (e.g.
> "EINVAL" for EINVAL). This would have the following advantages compared
> with strerror():
> - short, precise output in logs (every programmer knows "EINVAL" or
> "EACCES"). Easy to grep for.
> - no trouble with localizations. strerror output is localized depending on
> the customers LC_MESSAGES. So, you may get "Illegal Seek" or "Nicht
> erlaubter Seek" or "Repérage non permis" which is even harder to grep. You
> also may just get "????" if the code conversion is not supported by the
> C-Runtime.
> - making this function threadsafe is trivial. strerror() is not threadsafe
> and strerror_r() requires error checking.
>
> Does this make sense? What do you think?
>
> Thanks & Regards, Thomas
>