erpc

erpc copied to clipboard

The Thread class constructor based on thread_entry_t takes stackSize and stackPtr arguments which default to 0 if omitted. The stackSize (which becomes m_stackSize) is then used in the Thread::start() methods of the Windows, FreeRTOS and Zephyr ports (curiously, the Pthreads port ignores this argument entirely and just creates the thread with libpthread defaults). (There also appear to be some differences in which ports create the thread in the Thread::start() method vs the Thread::init() method, but that's a separate topic.)

Now, looking the TCP transport code which creates a thread to listen for connections using the above-mentioned Thread constructor here, there is absolutely no place where it could possibly be setting the m_stackSize value to anything other than the 0 that the constructor uses by default. That in turn means that the TCP transport's listening thread would be attempted to be created with a 0-sized stack (which maybe works in the Pthreads case since it is not used).

So, the questions are:

1. How is the TCP transport constructor supposed to influence the stack size of its listening thread (even if the stack is static, a valid non-zero size needs to be used)?
2. Is the TCP transport working just by luck and/or only on Pthreads (I realize this transport is marked "mostly for testing," but I'm failing to understand how it could be working even for the most basic testing cases on anything other than Pthreads)?

Hi eRPC user. Thank you for your interest and welcome. We hope you will enjoy this framework well.

@Hadatko @MichalPrincNXP do you by chance have any comments on the above? I can move ahead with various workarounds on my own, but I was hoping for some guidance/coordination that may lead to a PR contribution...

Hi, i will look on your question asap ;)

Thank you! 🙏

Hi, i will look on your question asap ;)

One more nudge @Hadatko?

Hi @berendo , sorry that it took so much time. I was busy with other work. Current tcp implementation is only for Linux/Mac where pthreads doesn't need stack attribute, so transport layer doesn't count with it.

Static implementation was some recent work and tcp transport also went trought update. So in future if there would be another port we would need to do transport more generic (add stack pointer and stack values into constructor i guess or something like that)

Here are some information regarding to init: