On Thu, Oct 06, 2022 at 10:32:56AM +0200, David Marchand wrote: > On Wed, Oct 5, 2022 at 7:07 PM Tyler Retzlaff > <roret...@linux.microsoft.com> wrote: > > > > Test basic functionality and demonstrate use of following thread > > lifetime api. > > > > * rte_thread_create > > * rte_thread_detach > > And, to some extent, rte_thread_equal. > > > * rte_thread_join > > > > Signed-off-by: Narcisa Vasile <navas...@microsoft.com> > > Signed-off-by: Tyler Retzlaff <roret...@linux.microsoft.com> > > --- > > app/test/test_threads.c | 54 > > +++++++++++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 52 insertions(+), 2 deletions(-) > > > > diff --git a/app/test/test_threads.c b/app/test/test_threads.c > > index b9d8b4e..1077373 100644 > > --- a/app/test/test_threads.c > > +++ b/app/test/test_threads.c > > @@ -14,7 +14,7 @@ > > > > static uint32_t thread_id_ready; > > > > -static void * > > +static uint32_t > > thread_main(void *arg) > > Stopping at this patch, I still see a build failure. > This prototype change makes it uncompatible with remaining calls to > pthread_create.
hmm, i must have made a mistake somewhere in the rebase. now i see what you mean about build failure @ patch 4 i was considering it only with the entire series applied i had not been testing individual patches in the series. sorry about that. > > This is fixed in patch 6 which I intend to squash here (and adding the > check on arg != NULL that is in patch 5). > Deal? i have no problem with that. now that i've read this can you confirm the only outstanding issue is whether to move code to eal_common_thread? i posted a follow up to thomas and i'm just waiting on his reply. if the reply is still a positive to move the code i can fix the above in a v6. Thomas waiting on your follow up regarding code move. thanks
