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
