On Thu, Apr 29, 2021 at 01:05:05PM +0100, Kinsella, Ray wrote: > > > On 29/04/2021 08:44, Thomas Monjalon wrote: > > 29/04/2021 02:50, Dmitry Kozlyuk: > >> 2021-04-02 18:38 (UTC-0700), Narcisa Ana Maria Vasile: > >>> --- /dev/null > >>> +++ b/lib/librte_eal/windows/include/rte_windows_thread_types.h > >>> @@ -0,0 +1,12 @@ > >>> +/* SPDX-License-Identifier: BSD-3-Clause > >>> + * Copyright(c) 2021 Microsoft Corporation > >>> + */ > >>> + > >>> +#ifndef _RTE_THREAD_TYPES_H_ > >>> +#define _RTE_THREAD_TYPES_H_ > >>> + > >>> +#include <rte_windows.h> > >>> + > >>> +typedef DWORD rte_thread_t; > >>> + > >>> +#endif /* _RTE_THREAD_TYPES_H_ */ > >> > >> pthread_t type in pthreads-win32 and winpthread is not 32 bit. > >> DPDK will have different ABI depending on a threading backend used. > >> Apps must know it at build time then. How do they discover it? > >> This is worth a warning in commit log and docs. > > > > Not sure this is an acceptable behaviour. > > In my opinion, ABI should not vary. > > +Cc Ray > > > > So pthread_t on Win32 should just map to the HANDLE datatype. > Which if memory serves is in fact a DWORD on Win32. > So I suspect that pthreads indirection is probably be just providing a > circuitous route to end up in the same place, a HANDLE > > IMHO > To absolutely guarantee no ABI change, we ought to be passing back void * not > rte_thread_t.
agreed, the type should be opaque. but may i suggest uintptr_t instead since void * still leaks implementation detail.
