On 20 January 2008 15:20, Huang Bambo wrote:
To duplicate the problem,
1. Run windows task manager , show handles of cygserver.
2. Run my program, it will create a message que, you will find the
cygserver process's handle increased by 4
3. Run ipcs command, you will find the que.
4. Run ipcrm command to remove this command, you will find the
cygserver's handles will only decrease by 2
5, go to 2 ,repeat the operation, you will find the handles owned by
cygserver will only increase.
You are seeing the cache growing after cygserver initial startup, but it
bottoms out quickly. I ran this command to generate a script file:
$ for (( x = 1 ; x 40 ; x++ )) ; do echo -e ./OceProxy.exe\nipcs\nipcrm-q
$(( $x * 65536 )) ; done | tee foosh
then cut and pasted the content into a console, while running
$ /usr/sbin/cygserver.exe --debug 21 | tee cs5.log
in a separate console (CYGWIN=server in both). The effect was to repeatedly
run your test, deleting the newly created queue after each run. Each time it
got to OceProxy.exe, it paused, and I noted the number of handles in cygserver
using sysinternals' process explorer; then pressed Ctrl+C to kill OceProxy and
let the loop delete the queue and repeat. Here are the numbers of handles I
observed each time OceProxy.exe was in the running state:
88
95
97
99
101
103
105
107
109
111
113
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
115
109
The last 109 is after the entire script finished; it's the resting level at
that point, and each further time you run and then kill OceProxy.exe you see
the number of handles rise and fall 109 - 115 - 109.
I'm guessing there's some kind of handle caching going on. I saved a dump
of the handles on two successive goes round the loop and diffed them:
/win/i/xtool/attatchs/OceProxyFrameworkDemo $ grep ^- a-vs-b.txt
-0x168 Event 0x001F0003 0x8213F7A0
-0x16C Event 0x001F0003 0x81B24140
-0x160 File\Device\NamedPipe\cygwin_lpc0x0012019F 0x82256F88
-0x180 File\Device\NamedPipe\cygwin_lpc0x0012019F 0x8214A1C8
-0x144 Process OceProxy.exe(324) 0x001F0FFF 0x81D28BA0
-0x178 Process OceProxy.exe(2064) 0x001F0FFF 0x81DE0020
/win/i/xtool/attatchs/OceProxyFrameworkDemo $ grep ^\+ a-vs-b.txt
+0x160 Event 0x001F0003 0x821666C0
+0x17C Event 0x001F0003 0x81E64520
+0x180 Event 0x001F0003 0x8225DCA0
+0x16C File\Device\NamedPipe\cygwin_lpc0x0012019F 0x81416028
+0x184 File\Device\NamedPipe\cygwin_lpc0x0012019F 0x81662AA8
+0x144 Process OceProxy.exe(508) 0x001F0FFF 0x818C8020
+0x18C Process OceProxy.exe(2084) 0x001F0FFF 0x81DA3920
+0x178 Thread cygserver.exe(1516): 2008 0x001F03FF 0x814891A0
So, each time we run the test, then stop it and delete the queue, it opens
and closes two events, two files and two process handles; and at least to
start with, it gains a thread and an event each time round. Perhaps there's
some kind of cache of worker threads in cygserver, each of which has a
shutdown event associated with it? It may be that it's firing up new threads
more often than it needs considering that the old queue has gone away. We'll
need to take a look at the source - I've no idea how cygserver works
internally.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
