qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.
Date: Fri, 18 Feb 2011 17:16:56 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]