Tcl Source Code

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:

Logged In: YES 
user_id=75003

Adapted patches to CVS head and committed.

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.

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.

Logged In: YES 
user_id=99573

What prevents the patch from beeing implemented ?
Rolf.

File Added - 12192: bug219311_patch1.0.zip

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.

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.

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.

Logged In: YES 
user_id=75003

This might affect or be affected by your rewrite of serials

Check whether Patch #103432 has fixed this.

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