On 22 March 2017 at 10:37, Paolo Bonzini <pbonz...@redhat.com> wrote:
> > > On 22/03/2017 09:48, Jiahuan Zhang wrote: > > > > > > On 22 March 2017 at 09:40, Paolo Bonzini <pbonz...@redhat.com > > <mailto:pbonz...@redhat.com>> wrote: > > > > > > > > I am using a windows named pipe to get the data from a window > > > > host program, which uses ReadFile () in char_win.c > > > > > > OK, bugs in the windows-specific char backend would be > > > unsurprising. > > > > > > I'm not entirely sure how the chardev layer works, but > > > at the pl011 end if we return 0 from our can_receive > > > function then the chardev layer should decide it has > > > nothing to do until the pl011 later calls > > > qemu_chr_fe_accept_input(), I think. > > > > > > I've cc'd Paolo and Marc-André Lureau as the chardev > > > maintainers. > > > > Windows named pipes do not support the equivalent of "select", > > so it's possible that they cause a busy wait. Try using a > > TCP socket instead and see if the bug goes away. > > > > > > Hi, I am trying to use a Windows socket for serial redirection instead > > of Windows named pipe. > > What do you mean "the equivalent of 'select'"? > > A function that lets a process sleep until data is available on the > socket. The solution is to rewrite Windows chardev handling in QEMU to > use threads or overlapped I/O. > > Yes, socket is working well. Will you add the "select" to pipe implementation? Or shall I look into it and fix? Since in my case, I prefer windows pipe to socket. But if I do, definitly, I will spend much more effort than you, the experts. > Paolo >