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).
Linux also supports (possibly due to this reason) SIGEV_THREAD_ID, which lets you specify a thread ID to send a signal to, although this is stated to be used internally. Or is there a way for an lpwork thread to temporarily get into a task's environment? 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. Best, Matias On Wed, Jan 27, 2021, at 14:45, Xiang Xiao wrote: > 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? > 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? > We have encountered this issue many times, and workaround by calling > file_open directly from the userspace, but it is obviously not the right > way to go. > > Thanks > Xiang > > On Tue, Jan 26, 2021 at 3:12 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > Yes, you are right. Perhaps this could be added to > > https://github.com/apache/incubator-nuttx/issues/1352 > > > > That is a different issue description but might still be a good location > > because both issues have the same solution. The solution to both issues > > is to enhance the OS by adding a new OS facility to start a pthread from > > within OS just as if pthread_create() were called from that application > > task. That is not really that difficult. The SIGEV_THREAD logic would > > then run on that pthread. > > > > This same facility is also needed to correct the implementation of the > > AIO APIs. They also should run on pthreads as well. However, I am not > > aware of any functional shortcoming of the current AIO implementation > > that would justify the change. > > > > The only unattractive thing about this solution is that is does require > > more resources and is less efficient in general. > > > > Greg > > > > On 1/26/2021 4:26 PM, Matias N. wrote: > > > Hi, > > > working with nimBLE I found that I had an issue when scheduling a > > callback to be made from within the signal handler for a timer, which was > > set with SIGEV_THREAD. The issue was that I was pushing to a POSIX queue > > from within the handler, and it was failing with BADFD. From debugging I > > realized that when trying to obtain the inode for the queue it was looking > > up at the open file descriptors from the lpwork thread, which of course > > would not share open file descriptors with main task. > > > > > > Since this is working for Linux (I had copied this part of the porting > > layer from Linux) my reasoning is that SIGEV_THREAD is there implemented as > > a thread that is a child of the process which registered the signal handler > > and thus shares the open file descriptors. In NuttX this is implemented via > > a work queue so this is not the case. > > > > > > Is my reading correct? If so, it may be worth adding this limitation to > > https://github.com/apache/incubator-nuttx/issues/1352 > > > > > > Best, > > > Matias > > >
