pthread_create concurrent thread limit

[H0neyBadger]

Hello,
(This issue might be out of newlib’s scope)
I m currently facing an issue with the pthread_create interface.

Despite mutex/barrier and sched_yield some threads never execute after reaching a specific number. Some threads are like frozen (hanged).

The number of running concurrent threads look limited.
Is there a way to increase this limit ?

I created the following snippet to isolate my issue.
https://gist.github.com/H0neyBadger/c080dd00c0dd77439bd8d41826d49d0c#file-main-cpp-L131
With thread count to 68, the job is running as expected.
With thread count to 69 (or greater) one or many threads are frozen. The thread barrier is never reached.

I m using nxlink and homebrew netloader to test my projects (with the latest devkitpro pacman on arch).

I spent a lot of time on this issue, and I m out of idea.
I hope you can help

[fincs]

This looks to me like you're hitting the homebrew process' resource limit on thread creation, i.e. not related to newlib at all.

[H0neyBadger]

thank you very much for your prompt reply and guidance.
I’m going raise the same issue to nx-hbmenu.
Maybe a good suggestion is to return EAGAIN form pthread_create when the limit is reached.
but feel free to close it if you think that issue in irrelevant.
Thank you again. ;-)

[fincs]

nx-hbmenu is just a graphical shell. You should raise it in nx-hbloader.

[fincs]

Also, can you check what this code prints?

u64 resource_limit_handle_value = INVALID_HANDLE;
svcGetInfo(&resource_limit_handle_value, InfoType_ResourceLimit, INVALID_HANDLE, 0);

u64 thread_cur_value = 0, thread_lim_value = 0;
svcGetResourceLimitCurrentValue(&thread_cur_value, (Handle)resource_limit_handle_value, LimitableResource_Threads);
svcGetResourceLimitLimitValue(&thread_lim_value, (Handle)resource_limit_handle_value, LimitableResource_Threads);

printf("thread_cur_value: %lu, thread_lim_value: %lu\n", thread_cur_value, thread_lim_value);

[H0neyBadger]

it returns (before the thread create loop)
"thread_cur_value: 28, thread_lim_value: 96"
(after the loop)
"thread_cur_value: 96, thread_lim_value: 96"
it confirms the 68 limit found earlier. thanks for the snippet.