On Feb 18, 2011, at 4:34 PM, Jan Kiszka wrote:
>
> This and the above handling of sigwait return codes changes the error
> handling strategy.
Did it ? I don't think so.
> So far we silently skipped errors, now we silently
> terminate the compatfd thread. I think none of both approaches is good.
I think that both silently terminate the compatfd. The previous code is:
do {
siginfo_t siginfo;
err = sigwaitinfo(&info->mask, &siginfo);
if (err == -1 && errno == EINTR) {
err = 0;
continue;
}
if (err > 0) {
char buffer[128];
size_t offset = 0;
memcpy(buffer, &err, sizeof(err));
while (offset < sizeof(buffer)) {
ssize_t len;
len = write(info->fd, buffer + offset,
sizeof(buffer) - offset);
if (len == -1 && errno == EINTR)
continue;
if (len <= 0) {
err = -1;
break;
}
offset += len;
}
}
} while (err >= 0);
So in case of any error, err is set to a negative value which exits the thread.
> Failing sigwait is likely a reason to bail out, but loudly, writing some
> error message to the console and triggering a shutdown of qemu.
I agree with that.
> An overflow of the compatfd pipe to the main thread may be due to some
> very unfortunate overload scenario. Not sure if that qualifies for a
> thread termination (definitely not for a silent one).
What do you mean by overflow ? Unless I am wrong, the fd is not non-blocking,
write will block.
> Error handling should probably be adjusted independently of this darwin
> build fix.
I agree too.
Tristan.
