My thinking is that maybe upon setting up the first SIGEV_THREAD notification
for a task, a child thread would be created, which would act as a worker,
waiting on some semaphore for example. The bad thing is that it would linger
until task is finished (not sure even how easy would be to ensure it is deleted
on task exit).
This would be difficult because in PROTECTED and KERNEL modes, the OS
has no knowledge of any user-space symbols. Creating a pthread is
different from starting a task because you have to the user-space
address of the pthread entry point. That is not knowable in the cases
where the OS is separately linked. So this could not be done by the
core OS as a general solution. It could be done in some library
function if we had a user-space crt0.o to start the task.
There is already a crt0.o for ELF modules and it could start such a thread.
Or is there a way for an lpwork thread to temporarily get into a task's
environment?
No, because an LP thread is a kernel thread. It is privileged and if it
were to run user code in supervisor mode, that would be a major security
hole.
BTW, for C++ global constructors I think there's also the issue that they are
only called at boot and not each time a task starts. At least I had that
problem in the past.
This would require a different build model with tasks (or at least
task-related constructors/destructors) that are separately built and a
crt0.o to start any threads.
So one solution to both problems is to make all tasks into separately
linked ELF modules.
