Public bug reported:
In 17.10, I'm running into a new problem. This didn't happen to me on
16.04.
I have some code that uses eventfds to signal things, and the code is
not working -- after writing the eventfd, it does not come back readable
from another thread using poll().
Here's a snippet from strace:
```
eventfd2(0, 0) = 5
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "OPEN FD 5\n", 10OPEN FD 5
) = 10
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
nanosleep({tv_sec=0, tv_nsec=100000000}, 0x7fffd0cea1a0) = 0
poll([{fd=5, events=POLLRDNORM}], 1, 100) = 0 (Timeout)
```
The write(1,... ) is debugging output. The nanosleep was intended to
see if sleeping a bit before polling would help. Note that the write(5,
...) and the poll() come from different threads.
Note that using two descriptors from a pipe() (which I do for other
platforms) is fine, so this is some kind of issue specific to eventfd.
Also, trying to reproduce this with a simpler single threaded program
did not succeed. I'm wondering if there is some underlying cache
synchronization problem?
I'm testing this in a VMware Fusion virtual machine (Fusion 10.1.1)
running on 2017 macbook pro (underlying OS is macOS 10.13).
For now I'm going to switch back to pipes, since eventfd() seems
unreliable -- if you can spot anything obviously wrong about the system
call sequence above, I'd love to hear it.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1761619
Title:
eventfd / poll interaction bug
Status in linux package in Ubuntu:
New
Bug description:
In 17.10, I'm running into a new problem. This didn't happen to me on
16.04.
I have some code that uses eventfds to signal things, and the code is
not working -- after writing the eventfd, it does not come back
readable from another thread using poll().
Here's a snippet from strace:
```
eventfd2(0, 0) = 5
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "OPEN FD 5\n", 10OPEN FD 5
) = 10
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
nanosleep({tv_sec=0, tv_nsec=100000000}, 0x7fffd0cea1a0) = 0
poll([{fd=5, events=POLLRDNORM}], 1, 100) = 0 (Timeout)
```
The write(1,... ) is debugging output. The nanosleep was intended to
see if sleeping a bit before polling would help. Note that the
write(5, ...) and the poll() come from different threads.
Note that using two descriptors from a pipe() (which I do for other
platforms) is fine, so this is some kind of issue specific to eventfd.
Also, trying to reproduce this with a simpler single threaded program
did not succeed. I'm wondering if there is some underlying cache
synchronization problem?
I'm testing this in a VMware Fusion virtual machine (Fusion 10.1.1)
running on 2017 macbook pro (underlying OS is macOS 10.13).
For now I'm going to switch back to pipes, since eventfd() seems
unreliable -- if you can spot anything obviously wrong about the
system call sequence above, I'd love to hear it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761619/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
