> Subject: Re: [PATCH v2 1/2] eal: error number enhancement for thread TLS > API > > External email: Use caution opening links or attachments > > > 2021-03-03 10:37, Tal Shnaiderman: > > > Subject: Re: [PATCH v2 1/2] eal: error number enhancement for thread > > > TLS API > > > > > > External email: Use caution opening links or attachments > > > > > > > > > 2021-03-02 17:26, Tal Shnaiderman: > > > > add error number reporting to rte_errno in all functions in the > > > > rte_thread_tls_* API. > > > > > > > > Suggested-by: Anatoly Burakov <anatoly.bura...@intel.com> > > > > Signed-off-by: Tal Shnaiderman <tal...@nvidia.com> > > > > --- > > > > lib/librte_eal/include/rte_thread.h | 6 +++--- > > > > lib/librte_eal/unix/rte_thread.c | 6 ++++++ > > > > lib/librte_eal/windows/rte_thread.c | 8 +++++++- > > > > 3 files changed, 16 insertions(+), 4 deletions(-) > > > > > > Using OS error codes for rte_errno isn't the right thing to do: this > > > way callers cannot write a portable check of rte_thread_*() result. > > > Consider returning some suitable stable values. OS-specific error > > > info can be logged at debug level, as it is already is some places. > > > > In Linux the error codes return are not OS specific (namely EAGAIN, > ENOMEM and EINVAL). > > > > The problem is that documentation on Windows doesn't publish which > error code can be returned from GetLastError() for the TLS functions. > > > > Or do we want to use the same errno for both OSs in case the functions fail > regardless to the failure reason? > > Yes, so that callers know which codes to check against regardless of the OS.
This is different from Anatoly's original suggestion that values would be potentially different on different OS's. Anatoly, is the approach suggested by Dmitry fine with you?
