Thread (290 messages) 290 messages, 13 authors, 2022-04-12

Re: [dpdk-dev] [PATCH v6 01/10] eal: add thread id and simple thread functions

flat view

From: Tyler Retzlaff <hidden>
Date: 2021-04-29 16:00:44

On Thu, Apr 29, 2021 at 01:05:05PM +0100, Kinsella, Ray wrote:

On 29/04/2021 08:44, Thomas Monjalon wrote:
quoted
29/04/2021 02:50, Dmitry Kozlyuk:
quoted
2021-04-02 18:38 (UTC-0700), Narcisa Ana Maria Vasile:
quoted
--- /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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help