RE: help with pthread_t deprecation / api changes

["Morten Brørup" <mb@smartsharesystems.com>]

+Bruce, FreeBSD EAL maintainer

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 2 December 2022 02.12
> 
> On Wed, Nov 30, 2022 at 02:54:27PM -0800, Tyler Retzlaff wrote:
> > hi folks,
> >
> > i'd like to continue work moving to our platform abstracted
> rte_thread
> > but ran into a hiccup. for some recent and not so recent apis it
> appears
> > they managed to slip in without ever being __experimental.
> >
> > as a function of the dpdk project api/abi policy this means we can't
> > change or remove some of these functions without following the
> > deprecation process.
> >
> > the apis that are causing me immediate difficulty are
> > rte_thread_setname and rte_ctrl_thread_create.
> 
> after looking in more detail at our current implementations of these
> functions i would like to backtrack a little and limit the scope of
> discussion to rte_thread_setname and rte_thread_getname.
> 
> as eal functions they aren't doing a good job in abstracting the
> environment for applications, meaning an application would have to wrap
> their use in platform conditional checks.

<rant>
This is one of the consequences of a bloated EAL.

How is an application supposed to run on top of an EAL that isn't fully implemented by the underlying environments?

I have complained about this before, but am not afraid to repeat it:
I wish the EAL wasn't treated as some catch-all library where it is easy to throw in new features, which really belong in separate libraries!
</rant>

> 
> current status.
> 
> rte_thread_getname
>   * freebsd, no implementation and it appears no possible support
>   * linux, implementation conditional on __GLIBC_PREREQ(2, 12)
>   * windows, can be implemented but isn't, noop success
>   * fortunately is marked __rte_experimental
>   * called in 1 place only from eal (logging)
> 
> i would propose to present a consistent abstraction the best thing to
> do
> here is just remove rte_thread_getname. providing a version that
> requires an application to do conditional dances / compilation based on
> platform gains nothing.

My initial thought was that it should be provided for symmetry reasons.
However, thinking about it, it is probably only used for debugging, trace, and similar. It is probably not used in any meaningful way by applications. So I won't oppose to removing it.

Alternatively:
If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.

> 
> rte_thread_setname
>   * freebsd, implemented, imposes no limit on name length, suppresses
> errors
>   * linux, implementation conditional on __GLIBC_PREREQ(2, 12), imposes
>     limit of 16 (including terminating NUL) on name length, may return
> an
>     error
>   * windows, can be implemented, no explicit limit on name length, may
>     return errors
>   * unfortunately not marked __rte_experimental
> 
> i would propose to provide a replacement with the name
> rte_thread_set_name with more consistent behavior across the 3
> platforms.
> 
>   * returns errors for platforms that return errors, but the caller
>     is free to ignore them.
>   * explicit limit of 16 (including terminating NUL) on name length,
>     names that are provided that exceed the limit are truncated without
>     error.

The function should not silently modify the provided data (i.e. truncate the name). I would prefer doing both: Return ERANGE (like pthread_setname_np()), but use the truncated name anyway. Then the application can choose to ignore or deal with the return code.