Hello again,

(I'm not posting this to SF because it has now become so slow it's unusable)

I think I can now produce a global analysis of the pipe-leak issue.

(1) This is a core issue, Tclx is a red herring here, it is only one
of many ways of exhibiting the problem;

(2) A core-only way is:

  # this leaks 2M per run in Windows
  # assuming "block.tcl" contains just "after 5000"
  set pr [open "|tclsh block.tcl" r];after 500;fconfigure $pr
-blocking 0;read $pr 1;close $pr

(3) The crux of the problem is the (now possiby obsolete)
PipeReaderThread being blocked on a ReadFile at [close]-time, implying
the use of the thermonuclear TerminateThread, which is known to have a
4k kernel leak in Windows.

(4) But in today's Windows (XPSP2), it leaks 2M, not 4k !!!

I don't know at which point in time the x500 amplification of the leak occured.
Notice that the situation producing it is rather unusual (it assumes a
long-running child which we close prematurely from the output side,
and only on  Windows where those tools (like vmstat) are not common).

Now there are IMO two parallel paths to follow simultaneously:

  (P1) investigate to understand the large leak

  (P2) (longer term) modernize the core to use waitable handles
(assuming they are really !), thus avoiding the need of ancillary
threads.

I would love to hear comments on this. I feel a bit shaky on Windows
to undertake (P2); and possibly a person who is literate in Windows
patch history migh home in on (P1) much fasterthan I would...

Thanks in advance,

-Alex

On 5/8/08, Alexandre Ferrieux <alexandre.ferrieux@[...].com>  wrote:
>  Hello,
> 
>  A few more insights on the pipe story (copy from bug 1958930)
> 
>  ------------------------------------------------------------------------------------------
----------------
> 
>  As to my prior interrogations, I have found the missing piece in the
>  puzzle: Yes, Tclx creates raw pipes, but No, it doesn't leave them
>  unadorned to the core ! Indeed, what I have just realized, is that
>  Tcl_MakeFileChannel does introspect the type, and in the pipe case calls
>  TclpCreateCommandChannel with an empty pid list ! This explains everything,
>  including the resort to the bad TerminateThread when the reader thread is
>  blocked in ReadFile etc...
> 
>  David, do you agree with the following conclusion:
>   - TclX's [pipe] fully interoperates with the (now obsolete) machinery in
>  tclWinPipe.c
>   - Hence it can be ported to the core (TIP304) with no change and no
>  worries
>   - It does have the old TerminateThread issue.
>   - This could be solved in post-NT era by direct wait on handles
>   - But this last move is orthogonal to TIP 304 and can wait a bit.
> 
>  -Alex
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core