#1299 [fcopy -command] on serial port floods the event queue

obsolete: 8.2.2
closed-fixed
5
2001-12-17
2000-10-26
Anonymous
No

OriginalBugID: 3648 Bug
Version: 8.2.2
SubmitDate: '1999-11-23'
LastModified: '1999-12-07'
Severity: SER
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
OS: Windows NT
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Alexandre Ferrieux

ReproducibleScript:
# to be fed to tclsh82.exe
set com [open COM1: r]
set nul [open c:/big.dat w]
fconfigure $com -translation binary -mode 115200,n,8,1
fconfigure $nul -translation binary

proc go args {puts CALLBACK;fcopy $::com $::nul -size 8000 -command go}

after idle {puts IDLE!!!!!!!}
go
vwait forever

ObservedBehavior:
Run the script while something is feeding the serial port at full speed (eg another PC via a null modem cable)."CALLBACK"s are slowly output as expected (every 550ms at this speed of 115200 bauds), but the IDLE!!!! comes only when you starve the port. Clearly the internal polling of the port (10ms) mistakenly postpones idletasks.
Notice that this happens only if the destination file is a true disk file (with nonzero write overheads). If you use NUL: instead there is no problem ! Also, with a true file the hard drive makes an awful noise, suggesting a lot of microscopic writes. Interestingly, a synchronous fcopy to the same file makes a normal noise (suggesting larger buffers). This happens on W95, W98, and NT. So the culprit is at the intersection of 8.2.2, WIndows, serial port, fcopy -command, nontrivial writes...

DesiredBehavior:
The idletask should occur immediately, just as it does on unix or if the file is NUL:

Discussion

  • Donal K. Fellows

    Does changing the -pollinterval option on the serial channel make any difference?

     
  • Donal K. Fellows

    • labels: 104250 --> 104247
     
  • Donal K. Fellows

    • labels: 104247 --> 27. Channel Types
     
  • Don Porter

    Don Porter - 2001-02-08

    Check whether Patch #103432 has fixed this.

     
  • Andreas Kupries

    Andreas Kupries - 2001-08-23

    Logged In: YES
    user_id=75003

    This might affect or be affected by your rewrite of serials

     
  • Andreas Kupries

    Andreas Kupries - 2001-08-23
    • assigned_to: nobody --> schroedter
     
  • Rolf Schroedter

    Rolf Schroedter - 2001-09-05

    Logged In: YES
    user_id=99573

    Sorry for responding so late - I just returned from
    vacation.

    There are a few specialities around serial ports:
    - A serial fileevent occures when there is at least
    1 char available.
    In the case above this should happen at nearly every
    event check.
    - A non-blocking read returns the number of available
    bytes in the input queue.

    When there are contineous fileevents obviously
    no IDLE callbacks will be executed.
    IMO that's intentional done.
    I also see, that -pollinterval doesn't change anything
    (see 3. below).

    Debugging the script above shows some strangeness
    when applied to the serial channel.
    It contineously performs non-blocking reads
    while resetting the event mask:

    1. SerialBlockProc(mode=1)
    # Set non-blocking mode
    2. SerialInputProc()
    # Returns a few bytes from the serial port
    # Writes these bytes to output channel
    (microscopic writes !!!)
    3. SerialWatchProc(mask=0)
    # mask=0 -> Tcl_SetMaxBlockTime() not called
    # That's why -pollinterval doesn't help.
    # This also resets the internal watch mask.
    4. SerialCheckProc()
    # Doesn't detect any event, because watch mask
    has been reset by 3.
    5. Repeat steps 2.-5.
    # Until 8000 bytes have been read
    6. SerialBlockProc(mode=0)
    # Restore original blocking mode

    It seems to me, that the there is at least 1 problem
    with fcopy and serial ports.

    tclIO.c:CopyData() considers only to cases after
    DoRead():
    size < 0: Error
    size == 0: Install a readable handler
    But in our case we almost always will have the case that
    0 < size < toRead
    IMO this should at least enable the -pollinterval option
    to avoid microscopic writes.
    But I'm not sure, whether installing an event handler for
    (0 < size < toRead) would help with the IDLE problem.

    BTW there one more potential problem with fcopy, when
    writing to a serial
    port:
    - The current (Tcl8.2-8.3) implementation of the serial
    driver doesn't support non-blocking writes.
    That will be changed with TIP#35.

    Rolf.

     
  • Rolf Schroedter

    Rolf Schroedter - 2001-10-08

    Logged In: YES
    user_id=99573

    IMO two changes are necessary to correct the behaviour
    of fcopy for serial inputs:

    1. Avoid flooding the event queue:
    Change tclWinSerial.c that is doesn't queue readable
    events faster then [fconfigure -pollinterval].

    2. fcopy correction:
    In tclIO.c CopyData() shouldn't disable event checking
    after reading (0 < size < toRead) bytes from the
    serial port.

    I'm discussing that with Andreas Kupries.

    Rolf.

     
  • Rolf Schroedter

    Rolf Schroedter - 2001-10-19

    Logged In: YES
    user_id=99573

    Here are the patches: bug219311_patch1.0.zip .
    It contains two *independent* patches:

    1. Bug #219311-A: Serial port may flood the event queue
    - tclWinSerial.c.patch: To be applied *after* TIP#35

    2. Bug ##219311-B: fcopy doesn't install readable
    handler for continuous incoming data
    - tclIO.c.patch: Correct handling of the input channel if
    (0<size<toRead)
    - io.test.patch: Added a test for this patch

    Rolf.

     
  • Rolf Schroedter

    Rolf Schroedter - 2001-12-14

    Logged In: YES
    user_id=99573

    What prevents the patch from beeing implemented ?
    Rolf.

     
  • Andreas Kupries

    Andreas Kupries - 2001-12-14

    Logged In: YES
    user_id=75003

    I believe they pass the testsuite, do they not ?
    In that case I ask you to commit. If you don't
    want to do this, assign this item to me. But
    note that I am on vacation from Dec 18 to Jan 6
    and will be busy with preparing for this in the
    next days.

     
  • Rolf Schroedter

    Rolf Schroedter - 2001-12-17
    • assigned_to: schroedter --> andreas_kupries
     
  • Rolf Schroedter

    Rolf Schroedter - 2001-12-17

    Logged In: YES
    user_id=99573

    Yes, they passed the tests on Linux and Win98/2000 in
    October. Moreover a special test (io-53.7 flooding fcopy)
    has been added.
    It would be fine, if you could apply the patch when you'll
    back in January. Have a nice vacation.
    Rolf.

     
  • Andreas Kupries

    Andreas Kupries - 2001-12-17

    Logged In: YES
    user_id=75003

    Adapted patches to CVS head and committed.

     
  • Andreas Kupries

    Andreas Kupries - 2001-12-17
    • status: open --> closed-fixed