To my bewilderment, I just discovered that both read and recvmsg are
required to be async-signal safe but readv isn't (some goes for
output routines).
Does someone know a reason for this bizarrely asymetrical arrangement?
On 2021-03-01, Rainer Weikusat <rweikusat@talktalk.net> wrote:
To my bewilderment, I just discovered that both read and recvmsg are
required to be async-signal safe but readv isn't (some goes for
output routines).
Eek.
Does someone know a reason for this bizarrely asymetrical arrangement?
If it's not simply an oversight, could it have something to do with some
dumb user space simulations of these functions?
If you don't actually have readv as a kernel primitive, what can
go wrong, signal-wise?
The user space implementation has to intercept errno to determine
success, and then do the copying from the linear buffer to the iovec.
To my bewilderment, I just discovered that both read and recvmsg are
required to be async-signal safe but readv isn't (some goes for
output routines).
Does someone know a reason for this bizarrely asymetrical arrangement?
Rainer Weikusat <rweikusat@talktalk.net> writes:
To my bewilderment, I just discovered that both read and recvmsg are >>required to be async-signal safe but readv isn't (some goes for
output routines).
Does someone know a reason for this bizarrely asymetrical arrangement?
Probably becomes some early implementations were library implementations built on calling read for each iovec element.
On 2021-03-01, Rainer Weikusat <rweikusat@talktalk.net> wrote:
To my bewilderment, I just discovered that both read and recvmsg are
required to be async-signal safe but readv isn't (some goes for
output routines).
Eek.
Does someone know a reason for this bizarrely asymetrical arrangement?
If it's not simply an oversight, ...
On 2021-03-01, Rainer Weikusat <rweikusat@talktalk.net> wrote:
To my bewilderment, I just discovered that both read and recvmsg are
required to be async-signal safe but readv isn't
The behavior is undefined if an unsafe function is interrupted by an
async signal handler which then calls an unsafe function, so what we
have to think about is how an interrupted and re-entered readv
could misbehave.
I think it is almost certainly an oversight that readv() isn't listed
in the table in XSH 2.4.3.
Kaz Kylheku <563-365-8930@kylheku.com> writes:
On 2021-03-01, Rainer Weikusat <rweikusat@talktalk.net> wrote:
To my bewilderment, I just discovered that both read and recvmsg are
required to be async-signal safe but readv isn't
[...]
The behavior is undefined if an unsafe function is interrupted by an
async signal handler which then calls an unsafe function, so what we
have to think about is how an interrupted and re-entered readv
could misbehave.
[...]
I don't think this should be applicable: Both recvmsg and sendmsg (I'm
really dealing with sockets and wanted to avoid handling a msghdr
structure for a receive operation using none of its extended features)
are required to be async-signal safe and they use scatter-gather-I/O,
too.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 230:39:14 |
Calls: | 6,624 |
Calls today: | 6 |
Files: | 12,171 |
Messages: | 5,319,307 |