#3465 thread::release on win32 does not release all memory

[Anonymous]

The original usenet posting -
All 5 messages in topic - view as tree

From: usenet....@googlemail.com - view profile
Date: Tues, Jul 11 2006 11:01 am
Email: usenet....@googlemail.com
Groups: comp.lang.tcl
Not yet rated
Rating:
show options

Reply | Reply to Author | Forward | Print | Individual
Message | Show original | Report Abuse | Find messages
by this author

I am running tcl 8.4 on Windows XP Pro 2002, SP2.
The simple script below fails on thread::create right
under 12,000
iterations.

Attempts to create any more threads fail in the same
shell once a call
to
thread::create fails.
Restarting tclsh and rerunning seems to work fine
within the limits
mentioned
above.

Would anyone know the reason this would fail?

---------------
tclsh
package require Thread
set i 1
while { 1 } {
set id [thread::create]
thread::release $id
puts -nonewline " $i "
flush stdout
update
incr i

}

From: David Gravereaux - view profile
Date: Wed, Jul 12 2006 12:17 pm
Email: David Gravereaux <davyg...@pobox.com>
Groups: comp.lang.tcl
Not yet rated
Rating:
show options

Reply | Reply to Author | Forward | Print | Individual
Message | Show original | Report Abuse | Find messages
by this author

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

joe,

I ran your script this time and I see what's going on :)

The Tclsh process runs out of virtual memory space!
Not committed
memory.. True VM allocations. I even tried the old
fashioned way with
thread::wait and thread::unwind that I personally know
for a fact do not
leak handles.. The issue is not a handle leak. The
issue is not
committed memory (apparently), but it appears that for
each thread
created, a slice of VM is given to it permanently and
that slice isn't
recouped (though it appears to have been uncommitted).

Joe, insert your script as a new bug. There's
something going on that's
a bit deeper than proper handle management.

the Old way (that has the same behavior):

package require Thread
set i 1
while { 1 } {
set id [thread::create {thread::wait}]
thread::send -async $id {thread::unwind}
puts -nonewline " $i "
flush stdout
update
incr i

}

[Zoran Vasiljevic]

Logged In: YES
user_id=95086

Hi!

This is I believe the side-effect of the thread memory allocator
which is known to be memory greedy as it was optimized on
speed and not memory usage. I have seen this behaviour on
all Unices as well, not only Windows. Although it seems that on
Unices is far less visible. I'm able to create and terminate about
30.000 threads and the VM usage increases about 1MB.

[Zoran Vasiljevic]

Logged In: YES
user_id=95086
Originator: NO

I will still leave this open but will try to replace
the greedy Tcl memory allocator with just calls
to regular system allocator and see if this helps.
If yes then we can think of making an alternate
allocator for Tcl OR even just simple use the
system-level one as those beasts are more
thread-aware today as they have been 5 year ago.

[Zoran Vasiljevic]

Perhaps this is a problem related to memory leak in the teardown logic.
I will need to investigate the memory leak problem first.

[Don Porter]

Testing the trunk (2.6.8) and thread-2-7-branch (2.7b1)
on Linux with the submitted test scripts I see no leaks
with the Tcl trunk.

Would be good for someone to confirm on Windows.

[Serg G. Brester]

I could also not reproduce it on linux, but in windows.
see also bug 3493120: https://sourceforge.net/tracker/?func=detail&aid=3493120&group_id=10894&atid=110894
Possible the same bug?
Have a linux kernel any "garbage collector" for therminated threads, its shared memory or something else?

[Don Porter]

ok then

[Don Porter]

Joe, did we decide this one is out of date?

That is, the leak problems on Windows are
already fixed? Thanks for closing this ticket
if you confirm.

[Joe Mistachkin]

Used the provided test script on Windows 8 and created 16K threads. Total memory used by the process was around 2MB. Therefore, no leak.