On 2011-02-18 16:50, Tristan Gingold wrote:
>
> 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.
Ah, sorry, oversaw that. In that case the patch is fine as it does not
change the existing behavior.
>
>> 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.
True. So any error returned here is a real one.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
