I think the independent ELF solution would again not be very good for constrained systems. The again, reading about SIGEV_THREAD makes me think that the specs are very loose in terms of what is guaranteed by the thread running the callback.
These kind of issues (and the fact that mixing signals with threads is not good) is what I think makes timerfd/signalfd/eventfd attractive. Having those the need for these kind of notifications is greatly diminished, as you simply poll/select on your own thread, and it can be done for other kind of fds simultaneously. Best, Matias On Wed, Jan 27, 2021, at 15:06, Gregory Nutt wrote: > > > 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. > > >
