[Tcl-bugs] [ tcl-Bugs-462317 ] Notification when there's no data

[<no...@so...>]

Bugs item #462317, was opened at 2001-09-17 11:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=462317&group_id=10894

Category: 24. Channel System
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Kevin O'Gorman (kogorman)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: Notification when there's no data

Initial Comment:
Using expect5.32 with Tcl8.4a3, my expect script
wedges.
I have used strace(1) and printfs to find that
ChannelTimerProc
is calling TclNotifyChannel, which causes expect to
perform
a blocking read.  This is usually okay, but sometimes
there's
no data, and the read blocks forever, because the
channel
corresponds to a child which is waiting for a command. 
Deadlock.

I can tell from the system call trace that the program
does NOT
have enough information to know whether the read will
block,
but it could guess that it would because the previous
read
returned a short reply.  However, the file descriptor
has not
been tested by select(), so the issuance of the notify
is probably
bogus.

My guess is that there should be something cancelling
the
timer, since it was started before the last successful
read,
and has just been running since then.

I have hundreds of megabytes of trace, but don't
understand
the internals well enough to make much more sense out
of them
than the above, though I'm working on it.  I can boil
the traces
down quite a bit if anyone can work with me on this.

Sorry I can't give a concise code sample, because I
don't know
how to provoke the error without my 1GB Oracle
database.
I have, however, included a boiled-down tail of one of
the
traces.

----------------------------------------------------------------------

>Comment By: Andreas Kupries (andreas_kupries)
Date: 2001-09-17 15:55

Message:
Logged In: YES 
user_id=75003

Some more comments. Given the last comments I believe you 
should have a look at how much is in the tcl bufers and how 
much the channel handler in expect tries to read from the 
channel.

Thanks for the trace btw. it helped a lot. A suggestion 
nevertheless: Adding __FILE__ and __LINE__ to the output 
would allow even better to pinpoint where each write call 
is.


----------------------------------------------------------------------

Comment By: Andreas Kupries (andreas_kupries)
Date: 2001-09-17 15:52

Message:
Logged In: YES 
user_id=75003

Does the deadlock happen with Tcl 8.3.3. too ?
Please attach the expect script too, if possible.
(Just so that we can take a look at the tcl side of the 
problem too).

It might be interesting [x] to switch the channel into non-
blocking mode and see what happens.

[x] I do not know how much control we have over the created 
channel. 

Note: The timer in question is activated when bytes are 
waiting in the input queue of the channel in question. It 
basically generates artifical fileevents to push these 
bytes into the channel handlers.

Problem is, if there are for example 12 bytes waiting in 
the tcl buffers and then a blocking read is issued from the 
eventhandler for more than 2 bytes the system will try to 
read the missing bytes from the OS. This can cause the 
deadlock too.

Are you able to trace execution inside of expact too ?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=462317&group_id=10894