OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/lib/posix/options/eventfd.c

24 lines
424 B
C
Raw Normal View History

lib: posix: Add support for eventfd This implements a file descriptor used for event notification that behaves like the eventfd in Linux. The eventfd supports nonblocking operation by setting the EFD_NONBLOCK flag and semaphore operation by settings the EFD_SEMAPHORE flag. The major use case for this is when using poll() and the sockets that you poll are dynamic. When a new socket needs to be added to the poll, there must be some way to wake the thread and update the pollfds before calling poll again. One way to solve it is to have a timeout set in the poll call and only update the pollfds during a timeout but that is not a very nice solution. By instead including an eventfd in the pollfds, it is possible to wake the polling thread by simply writing to the eventfd. Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
2019-11-05 23:09:42 +08:00
/*
posix: eventfd: fix dependency cycle between net and posix Until recently, the posix api was purely a consumer of the network subsystem. However, a dependency cycle was added as a stop-gap solution for challenges with the native platform. Specifically, 1. eventfd symbols conflict with those of the host 2. eventfd was excluded from native libc builds via cmake If any part of the posix were then to select the network subsystem (which is a legitimate use case, given that networking is a part of the posix api), we would get a build error due to the Kconfig dependency cycle. As usual, with dependency cycles, the cycle can be broken via a third, mutual dependency. What is the third mutual dependency? Naturally, it is ZVFS which was planned some time ago. ZVFS will be where we collect file-descriptor and FILE-pointer APIs so that we can ensure consistency for Zephyr users. This change deprecates EVENTFD_MAX in favour of ZVFS_EVENTFD_MAX. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
2024-05-29 07:39:06 +08:00
* Copyright (c) 2024, Tenstorrent AI ULC
lib: posix: Add support for eventfd This implements a file descriptor used for event notification that behaves like the eventfd in Linux. The eventfd supports nonblocking operation by setting the EFD_NONBLOCK flag and semaphore operation by settings the EFD_SEMAPHORE flag. The major use case for this is when using poll() and the sockets that you poll are dynamic. When a new socket needs to be added to the poll, there must be some way to wake the thread and update the pollfds before calling poll again. One way to solve it is to have a timeout set in the poll call and only update the pollfds during a timeout but that is not a very nice solution. By instead including an eventfd in the pollfds, it is possible to wake the polling thread by simply writing to the eventfd. Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
2019-11-05 23:09:42 +08:00
*
* SPDX-License-Identifier: Apache-2.0
*/
posix: eventfd: revise locking, signaling, and allocation TL;DR - a complete rewrite. Previously, the prototypical `eventfd()` usage (one thread performing a blocking `read()`, followed by another thread performing a `write()`) would deadlock Zephyr. This shortcoming has existed in Zephyr's `eventfd()` implementation from the start and the suggested workaround was to use `poll()`. However, that is not sufficient for integrating 3rd-party libraries that may rely on proper `eventfd()` blocking operations such as `eventfd_read()` and `eventfd_write()`. The culprit was the per-fdtable-entry `struct k_mutex`. Here we perform a minor revision of the locking strategy and employ `k_condvar_broadcast()` and `k_condvar_wait()` to signal and wait on the holder of a given `struct k_mutex`. It is important to note, however, that the primary means of synchronizing the eventfd state is actually the eventfd spinlock. The fdtable mutex and condition variable are mainly used for the purposes of blocking io (r,w,close) and are not used in the code path of non-blocking reads. The `wait_q` and `k_poll_signal` entries were removed from `struct eventfd` as they were unnecessary. Additionally, switch to using a bitarray because it is possibly faster than linear search for allocating and deallocating eventfd resources. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
2023-05-31 05:16:20 +08:00
#include <zephyr/posix/sys/eventfd.h>
posix: eventfd: fix dependency cycle between net and posix Until recently, the posix api was purely a consumer of the network subsystem. However, a dependency cycle was added as a stop-gap solution for challenges with the native platform. Specifically, 1. eventfd symbols conflict with those of the host 2. eventfd was excluded from native libc builds via cmake If any part of the posix were then to select the network subsystem (which is a legitimate use case, given that networking is a part of the posix api), we would get a build error due to the Kconfig dependency cycle. As usual, with dependency cycles, the cycle can be broken via a third, mutual dependency. What is the third mutual dependency? Naturally, it is ZVFS which was planned some time ago. ZVFS will be where we collect file-descriptor and FILE-pointer APIs so that we can ensure consistency for Zephyr users. This change deprecates EVENTFD_MAX in favour of ZVFS_EVENTFD_MAX. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
2024-05-29 07:39:06 +08:00
#include <zephyr/zvfs/eventfd.h>
posix: eventfd: revise locking, signaling, and allocation TL;DR - a complete rewrite. Previously, the prototypical `eventfd()` usage (one thread performing a blocking `read()`, followed by another thread performing a `write()`) would deadlock Zephyr. This shortcoming has existed in Zephyr's `eventfd()` implementation from the start and the suggested workaround was to use `poll()`. However, that is not sufficient for integrating 3rd-party libraries that may rely on proper `eventfd()` blocking operations such as `eventfd_read()` and `eventfd_write()`. The culprit was the per-fdtable-entry `struct k_mutex`. Here we perform a minor revision of the locking strategy and employ `k_condvar_broadcast()` and `k_condvar_wait()` to signal and wait on the holder of a given `struct k_mutex`. It is important to note, however, that the primary means of synchronizing the eventfd state is actually the eventfd spinlock. The fdtable mutex and condition variable are mainly used for the purposes of blocking io (r,w,close) and are not used in the code path of non-blocking reads. The `wait_q` and `k_poll_signal` entries were removed from `struct eventfd` as they were unnecessary. Additionally, switch to using a bitarray because it is possibly faster than linear search for allocating and deallocating eventfd resources. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
2023-05-31 05:16:20 +08:00
int eventfd(unsigned int initval, int flags)
{
posix: eventfd: fix dependency cycle between net and posix Until recently, the posix api was purely a consumer of the network subsystem. However, a dependency cycle was added as a stop-gap solution for challenges with the native platform. Specifically, 1. eventfd symbols conflict with those of the host 2. eventfd was excluded from native libc builds via cmake If any part of the posix were then to select the network subsystem (which is a legitimate use case, given that networking is a part of the posix api), we would get a build error due to the Kconfig dependency cycle. As usual, with dependency cycles, the cycle can be broken via a third, mutual dependency. What is the third mutual dependency? Naturally, it is ZVFS which was planned some time ago. ZVFS will be where we collect file-descriptor and FILE-pointer APIs so that we can ensure consistency for Zephyr users. This change deprecates EVENTFD_MAX in favour of ZVFS_EVENTFD_MAX. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
2024-05-29 07:39:06 +08:00
return zvfs_eventfd(initval, flags);
lib: posix: Add support for eventfd This implements a file descriptor used for event notification that behaves like the eventfd in Linux. The eventfd supports nonblocking operation by setting the EFD_NONBLOCK flag and semaphore operation by settings the EFD_SEMAPHORE flag. The major use case for this is when using poll() and the sockets that you poll are dynamic. When a new socket needs to be added to the poll, there must be some way to wake the thread and update the pollfds before calling poll again. One way to solve it is to have a timeout set in the poll call and only update the pollfds during a timeout but that is not a very nice solution. By instead including an eventfd in the pollfds, it is possible to wake the polling thread by simply writing to the eventfd. Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
2019-11-05 23:09:42 +08:00
}
posix: eventfd: un-inline eventfd_read() and eventfd_write() There is no major benefit to haveing `eventfd_read()` and `eventfd_write()` as `static inline` functions and it is arguably much easier to solve the deadlock bug when they are not `inline`. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
2023-05-30 20:33:37 +08:00
int eventfd_read(int fd, eventfd_t *value)
{
posix: eventfd: fix dependency cycle between net and posix Until recently, the posix api was purely a consumer of the network subsystem. However, a dependency cycle was added as a stop-gap solution for challenges with the native platform. Specifically, 1. eventfd symbols conflict with those of the host 2. eventfd was excluded from native libc builds via cmake If any part of the posix were then to select the network subsystem (which is a legitimate use case, given that networking is a part of the posix api), we would get a build error due to the Kconfig dependency cycle. As usual, with dependency cycles, the cycle can be broken via a third, mutual dependency. What is the third mutual dependency? Naturally, it is ZVFS which was planned some time ago. ZVFS will be where we collect file-descriptor and FILE-pointer APIs so that we can ensure consistency for Zephyr users. This change deprecates EVENTFD_MAX in favour of ZVFS_EVENTFD_MAX. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
2024-05-29 07:39:06 +08:00
return zvfs_eventfd_read(fd, value);
posix: eventfd: un-inline eventfd_read() and eventfd_write() There is no major benefit to haveing `eventfd_read()` and `eventfd_write()` as `static inline` functions and it is arguably much easier to solve the deadlock bug when they are not `inline`. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
2023-05-30 20:33:37 +08:00
}
int eventfd_write(int fd, eventfd_t value)
{
posix: eventfd: fix dependency cycle between net and posix Until recently, the posix api was purely a consumer of the network subsystem. However, a dependency cycle was added as a stop-gap solution for challenges with the native platform. Specifically, 1. eventfd symbols conflict with those of the host 2. eventfd was excluded from native libc builds via cmake If any part of the posix were then to select the network subsystem (which is a legitimate use case, given that networking is a part of the posix api), we would get a build error due to the Kconfig dependency cycle. As usual, with dependency cycles, the cycle can be broken via a third, mutual dependency. What is the third mutual dependency? Naturally, it is ZVFS which was planned some time ago. ZVFS will be where we collect file-descriptor and FILE-pointer APIs so that we can ensure consistency for Zephyr users. This change deprecates EVENTFD_MAX in favour of ZVFS_EVENTFD_MAX. Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
2024-05-29 07:39:06 +08:00
return zvfs_eventfd_write(fd, value);
posix: eventfd: un-inline eventfd_read() and eventfd_write() There is no major benefit to haveing `eventfd_read()` and `eventfd_write()` as `static inline` functions and it is arguably much easier to solve the deadlock bug when they are not `inline`. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
2023-05-30 20:33:37 +08:00
}