All global C++ objects are constructed in init task, so if these objects
call open, fopen or fstream related API, the similar issue happens too. How
can we fix this issue?
In order to do that, I think that each application task would have to
separately linked as they are with ELF modules or in KERNEL mode. There
is no issue in those cases.
BTW, is it acceptable to create a pthread in each task to
process SIGEV_THREAD dedicatedly in the small embedded device? Can we find
a lightweight solution to fix it?
A straight-forward solution is easy, but a lightweight solution is not
so easy, depending upon what you consider to be lightweight. It is
difficult to imagine doing that with less then 1-2Kb or RAM for stack
and OS structures.
Perhaps you could use a pool of application threads as is done with the
kernel threads for the low-priority work queue. So you could have a
small number of threads that service all tasks. When a user-space
thread is needed, it could be removed from the pool and be assigned to
the task to run the event. When the event processing completes, the
thread returned to the pool until it is again needed. Tasks could wait
for availability if there are no available threads in the pool.
But that is not so easy.
