Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.

[Dmitry Timoshkov]

Wolfgang Walter  wrote:
> I think that happens:
> - application writes data to com port.
> - all is written, serial buffer is empty
> - application calls  WaitCommEvent()
> - wait_on() is called
> - wait_on() calls get_irq_info()
> - get_irq_info() sets commio->irq_info->temt = 1
> - wait_on() calls check_events() and uses sets commio->irq_info for old an new
> - so old->temt == new->temt and EV_TXEMPTY is not set
> - if there are no other events (in real world basically EV_RXCHAR):
> - wait_for_event() is startet with commio->irq_info->temt set to one
> - wait_for_event() calls get_irq_info() with new_irq_info()
> - get_irq_info() sets new_irq_info->temt = 1 because the buffer is still empty
> - wait_for_event() calls check_events() with new_irq_info and commio->irq_info
> - again check_events() will not set EV_TXEMPTY as both have temt == 1
>
> It seems that we do not recover from that hang.
>
> Please correct me if I misread the code and I'm wrong.
>
> I think it's better if WaitCommEvent() returns with EV_TXEMPTY even if there 
> has no new data been sent in between:

That means that WaitCommEvent(EV_TXEMPTY) without any prior WriteFile
would always return success and signal the EV_TXEMPTY event. My tests
show that WaitCommEvent(EV_TXEMPTY) fails with a timeout in this case.
Since the serial device is very slow it should be unlikely that after
successful WriteFile() with some data WaitCommEvent() sees an already
empty transmitter's output queue.