-
Just as a follow up: The problem is caused by doing pool.resize at regular intervals. It doesn't matter whether the number of threads is increased or decreased.
Just to outline my use of threadpool: I initialise with a number of threads (e.g. 50). Then incoming requests get passed on to the pool using schedule. At regular intervals a monitor thread wakes and checks the number of active...
2009-09-22 21:58:39 UTC in threadpool
-
Here is the valgrind output from the threadpool specific part of my daemon which grows to about 3G in an hour. Any help appreciated.
==11428== Thread 1:
==11428==
==11428== 7,200 bytes in 50 blocks are possibly lost in loss record 13 of 14
==11428== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==11428== by 0x4010C7B: _dl_allocate_tls (in /lib/ld-2.7.so)
==11428== by 0x42CF672...
2009-09-22 17:43:50 UTC in threadpool
-
I can confirm this on x386 and amd64. Leakage here is huge actually. Can someone confirm this? I'll send a valgrind memcheck report soon.
Maybe needs starting a new thread as it's not windows specific.
2009-09-22 17:10:36 UTC in threadpool
-
Thanks for this. I'm also tracing some bug in PoolExecutor at the moment. Do you know does Eric still monitor this project?.
2009-08-26 12:55:01 UTC in ZThread
-
mimo committed revision 42 to the Greylist Policy Service SVN repository, changing 4 files.
2009-07-31 23:27:43 UTC in Greylist Policy Service
