search

apache / nuttx

Apache NuttX is a mature, real-time embedded operating system (RTOS)
https://nuttx.apache.org/
Apache License 2.0
2.83k stars 1.17k forks source link

Limited, non-complient SIGEV_THREAD event handling #1352

Open patacongo opened 4 years ago

patacongo commented 4 years ago

POSIX structure struct sigevent describes how a signal event should be handled. The sigev_notify field, in particular describes how the signal event should be notified. On important option is the SIGEV_THREAD notification method. The Linux man page provides more detail than does OpenGroup.org:

   SIGEV_THREAD
          Notify the process by invoking sigev_notify_function "as if"
          it were the start function of a new thread.  (Among the
          implementation possibilities here are that each timer
          notification could result in the creation of a new thread, or
          that a single thread is created to receive all notifications.)
          The function is invoked with sigev_value as its sole argument.
          If sigev_notify_attributes is not NULL, it should point to a
          pthread_attr_t structure that defines attributes for the new
          thread (see pthread_attr_init(3)).

The current implementation of support for SIGEV_THREAD is available only in the FLAT build mode because it uses the OS work queues to perform the callback. The correct approach and the only alternative for the PROTECTED and KERNE builds would be to create pthreads in the user space to perform the callbacks. That is not a very attractive solution due to performance issues. It would also require some additional logic to specify the TCB of the parent so that the pthread could be bound to the correct task group.

There is also some user-space logic in libs/libc/aio/lio_listio.c. That logic could use the user-space work queue for the callbacks.

protobits commented 3 years ago

A related issue is that, since SIGEV_THREAD is using a worker to run the supplied callback, this means that it does not share the same environment as the task which initialized the callback in the first place. This means that it is not possible to access resources such as the task's open file descriptors from within the callback.

xiaoxiang781216 commented 3 years ago

Yes, it is a very big limitation, we also hit too in many different scenario.