Re: DoModal isn't reentrant but failure mode could be improved

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message news:1o9cq1919ki9e0046kug7bru64qai8ig4s@xxxxxxxxxx
See below...
On Mon, 19 Dec 2005 11:28:43 +0900, "Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote: 
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:uut6q15ivvun043k81tppahov96dp6u516@xxxxxxxxxx

so to call DoModal twice, it means you have not declared the variable as a local variable in a function.

I see what you mean. The dialog should be newly created every time it's going to be displayed, instead of being created once at program start and then every time assigning two of its CString members before calling DoModal.

Correct. The cost of creating the CDialog is so infinitesimal that there is no reason it would be created at program startup. You save nothing important. 

OK.

Yes this would avoid the present behaviour that uses 100% of the CPU and renders the program non-responding. As well, if it's really appropriate for the application to have two (or more) modal dialog boxes on the screen, it will be able to do so.

This is a very odd concept. What does it mean to have two modal dialogs up at the same time? While a given dialog invoked by DoModal can itself invoke a second dialog,

No, the parent creates a second modal dialog with the same type as the first one. The parent receives a Windows Message that causes it to inform the user that a serial overrun (or other error) occured. The reason such a Windows Message reaches the parent even while the first modal dialog is still on the screen is that it's not a keyboard or mouse input message, and CDialog's message loop retrieves it and dispatches it.

The unexpected interactions cannot be designed out of existence, but the responses can be designed to avoid attempting reentrant calls to DoModal.

There are a lot of problems when multiple modal dialogs get involved. [...] Example: closing a dialog enables the parent of the dialog. What is the system going to do when you close one of the modal dialogs but not another? I suspect that nothing good is going to happen.

Ack. It's a good thing that I settled on displaying modeless dialog boxes for situations that were previously doing reentrant calls to DoModal.

Serial port overruns can be avoided by increasing the internal buffer size for the serial port.

I've seen a few web pages recommend reducing the internal receive buffer size from 14 to 8. I can't quite figure this out. Temporarily I seemed to understand the idea of trying to make the UART send an additional interrupt when the buffer's 8th byte gets filled (or maybe on every byte) but we still really want the UART to continue buffering while it's still necessary. Later I figured out that if video drivers or other unknown parts of Windows XP are masking the interrupt for more than 1ms, it's not going to matter how aggressively the UART asserts the interrupts. By private e-mail someone pointed me to some USB-serial adapters that have 384-byte receive buffers, and this does seem to be helping.

I've done a lot of high-speed serial communication and I've never seen a data overrun, even at 115200. 

I have.

If there's something that masks interrupts for > 1ms, you have a very bad driver in the OS.

Agreed. Several people have posted opinions that video drivers are a big cause of this.

Popping up a dialog box each time there's a serial overrun is bad practice. You could, if they happen as often as you think, generate dozens of these. There are few things more annoying than coming in after lunch and having to dismiss two dozen message boxes

Well, the original code wasn't expecting the possibility that more than one could be detected in that short a time. That's how this thread got started. And again it seems fortunate that I settled on a non-modal dialog for these kinds of occurences, and yes I do add each as it occurs to a list in one non-modal dialog.

In fact, if there's even one [modal dialog], it is a Really Bad Idea, because it steals the focus of attention from the user at inappropriate times.

The intention of the modal dialog was to ask the user from what point the user wants to resume or retry.

Consider an example which fortunately isn't the kind of device we're dealing with this time, but suppose it had mechanical moving components. And suppose we didn't wait for the user to choose what next action to perform, suppose we just proceeded to send the next command to the device without knowing what the device's response was to the previous command (because of overrun). We might lose clients in a somewhat more violent manner than you were thinking of. 

.

Relevant Pages

  • Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er
    ... serial driver PMC MSP71xx, ... interrupt, ... methods and not UART types. ... THRI interrupt -- it signifies that the TX shift register is empty, ...
    (Linux-Kernel)
  • [PATCH] 8250 UART backup timer
    ... The patch below works around a minor bug found in the UART of the ... The problem is that the UART does not reassert the THRE ... RX interrupt kicks it into working again (ie. an unattended reboot could ... static void serial8250_timeout ...
    (Linux-Kernel)
  • RE: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er
    ... serial driver PMC MSP71xx, ... +#ifdef CONFIG_PMC_MSP ... write will cause an interrupt, ... of UART registers, it's not specific to the DesignWare UART. ...
    (Linux-Kernel)
  • Re: [PATCH] 8250 UART backup timer
    ... The problem is that the UART does not reassert the THRE ... RX interrupt kicks it into working again (ie. an unattended reboot could ... and removes races in the bug detection code. ...
    (Linux-Kernel)
  • Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler
    ... this happen when I must receive a char, i have an overrun. ... they share the same interrupt line... ... So, while the timer interrupt handler is running, the serial handler ... Notice that the HRT interrupt handler is quite heavy and takes a long ...
    (Linux-Kernel)