25/01/2023 23:36, Tyler Retzlaff: > hi, > > i'm looking for some guidance when cleaning up / removing the remaining > shim functions for pthread in windows and i'm not sure how our > deprecation notice / policies apply. > > windows has been providing lib/eal/windows/include/pthread.h shim that > allowed applications to use e.g. pthread_xxx functions on windows. > > these shim functions were all being provided as inline functions and > were not part of the EAL api but on windows they were implicitly part of > the api surface exposed (to windows only). on posix platforms applications > did not rely on EAL for pthread abi or api (obviously). > > recently we introduced a set of platform agnostic thread api in the EAL. > the functions were marked __rte_experimental as a part of new API > addition policy. > > what's the most appropriate way to remove the pthread_xxx shim inline > functions from lib/eal/windows/include/pthread.h? do we have to wait the > full deprecation notice period which can't be started until we make the > new functions stable? also keeping in mind we can't actually mark inline > functions __rte_deprecated. > > is this a special case where we can just rip them out and break > compilation?
Probably yes. > input is appreciated, particularly from any consumers of the windows > port who might be unhappy. I think there is not too much users of Windows DPDK yet. I would be in favor of just removing the pthread shim layer for Windows when rte_thread equivalent is declared stable.
