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
>

Reply via email to