You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/07/02 16:28:54 UTC

[GitHub] [incubator-nuttx] patacongo opened a new issue #1352: Limited, non-complient SIGEV_THREAD event handling

patacongo opened a new issue #1352:
URL: https://github.com/apache/incubator-nuttx/issues/1352


   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.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #1352: Limited, non-complient SIGEV_THREAD event handling

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #1352:
URL: https://github.com/apache/incubator-nuttx/issues/1352#issuecomment-768020483


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


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [incubator-nuttx] v01d commented on issue #1352: Limited, non-complient SIGEV_THREAD event handling

Posted by GitBox <gi...@apache.org>.
v01d commented on issue #1352:
URL: https://github.com/apache/incubator-nuttx/issues/1352#issuecomment-767939825


   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.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org