apache / apache/nuttx

Limited, non-complient SIGEV_THREAD event handling

Open
#1,352 2 comments 0 reactions 0 assignees View on GitHub
Area: Standards Type: Bug
Dominant language
C
Stars
4k
Forks
1.7k
Avg merge
1d 17h
Merged PRs (30d)
237

Description

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.