summaryrefslogtreecommitdiffhomepage
path: root/test/syscalls/linux/signalfd.cc
AgeCommit message (Collapse)Author
2020-12-04Initialize has_tid for correctness.Adin Scannell
PiperOrigin-RevId: 345763209
2020-02-19Add basic microbenchmarks.Adin Scannell
PiperOrigin-RevId: 296104390
2020-01-17Convert EventMask to uint64Andrei Vagin
It is used for signalfd where the maximum signal is 64. PiperOrigin-RevId: 290331008
2019-10-25test/syscall: Remove duplicated gtest/gtest.h.Haibo
Signed-off-by: Haibo Xu <haibo.xu@arm.com> Change-Id: I05a7ec69b98b88931ba4a8adb3e8a7b822006001 COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/1023 from xiaobo55x:syscall_test d44a8b1f827ed4081997af96cd58ba7449e0a9e1 PiperOrigin-RevId: 276740442
2019-10-10Fix signalfd polling.Adin Scannell
The signalfd descriptors otherwise always show as available. This can lead programs to spin, assuming they are looking to see what signals are pending. Updates #139 PiperOrigin-RevId: 274017890
2019-09-18Signalfd supportAdin Scannell
Note that the exact semantics for these signalfds are slightly different from Linux. These signalfds are bound to the process at creation time. Reads, polls, etc. are all associated with signals directed at that task. In Linux, all signalfd operations are associated with current, regardless of where the signalfd originated. In practice, this should not be an issue given how signalfds are used. In order to fix this however, we will need to plumb the context through all the event APIs. This gets complicated really quickly, because the waiter APIs are all netstack-specific, and not generally exposed to the context. Probably not worthwhile fixing immediately. PiperOrigin-RevId: 269901749