ELF solution has to load the code to RAM, the overhead is too big to use for XIP system.
> -----Original Message----- > From: Matias N. <mat...@imap.cc> > Sent: Thursday, January 28, 2021 2:17 AM > To: dev@nuttx.apache.org > Subject: Re: limitation in SIGEV_THREAD? > > 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. > > > > > >
