Re: More Test 15 [CGF please comment]

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

At 04:12 PM 4/11/2001 -0400, Christopher Faylor wrote:
>On Wed, Apr 11, 2001 at 12:26:42AM -0400, Pierre A. Humblet wrote:
>>Chris,
>>
>>The Xserver code contains the following line
>> i = Select (MaxClients, &LastSelectMask, NULL, NULL, wt);
>>wt is set to 10 ms and Select is #defined as select()
>>By using gdb and netstat, I observe 
>>1) that the call to select() generates a new connection
>>2) that, after a while, a large number of connections exist
>>3) that after about ~ 2000 calls select() doesn't return.
>>All of that on WinMe. I have no idea why it is so, either.
>
>So, you are again mentioning that you are seeing a "connection".
>
>A connection, to what?

To itself... While the XServer runs "netstat -a | sort " 
shows THOUSANDS of lines such as (hpn5170 is the local host)
  TCP    hpn5170:1103           localhost:1102         TIME_WAIT
  TCP    hpn5170:1105           localhost:1104         TIME_WAIT
  TCP    hpn5170:1107           localhost:1106         TIME_WAIT
  TCP    hpn5170:1111           localhost:1110         TIME_WAIT
  TCP    hpn5170:1113           localhost:1112         TIME_WAIT
  TCP    hpn5170:1115           localhost:1114         TIME_WAIT
  TCP    hpn5170:1117           localhost:1116         TIME_WAIT
See also
http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg00297.html
http://sources.redhat.com/ml/cygwin-xfree/2001-q2/msg00272.html

>If you think that select is at fault, then look at the socket
>specific code in select.cc in the Cygwin DLL.

select() is creating sockets on lines 1275 (start_thread_socket),
which does a listen(), and 1331 (socket_cleanup), which connects()
to the first socket. 
This connect() causes winsock_select() to return and the thread_socket 
to terminate. The connection is immediately shutdown() after the connect().
This logic seems to be an ingenious trick to force a return from 
winsock_select() [when select() wants to return for another reason]
and to cleanup. 

Experience shows that the second socket doesn't disappear immediately and 
can be seen with netstat on all the platforms. On WinME some timeout
must be longer, thousands of sockets accumulate, and eventually select()
does not return 
(by the way, nice application of Little's law in queueing theory). 

I don't see any bug per se in the code. Using setsockopt() to set 
SO_LINGER with an interval of 0 (default is NO_LINGER, which does 
a graceful close) would force a hard close (!). Perhaps this will 
cause a fast release of the socket, which the method is relying on
to work when select() is called repeatedly at short intervals.   
See http://msdn.microsoft.com/library/psdk/winsock/wsapiref_714i.htm

*******
Now the better news:
As you wrote in

Re: Chris: message queues and new windows (was select() details)

>Are you saying that X-Windows is not adding windows handle events to its
>select() call?  It sounds like an obvious win to do this.

this is indeed the obvious (but apparently little known) thing to do
instead of polling every 10 ms. Thanks for implementing /dev/windows. 

Harold has put this in Test 17, and  select() is thus called less often.
With twm, 1 xterm and 1 xclock, the number of sockets visible with
netstat -a does not exceed about 1100 on my WinME. This is low enough 
that everything works for now, although I expect eventual freezes
and messages to this list.

As I couldn't find much explanations of what /dev/windows does, 
I was asking you about it. This led to
>If you have specific questions on an implementation detail, I'll try
>to accomodate you but "What is this used for?" is just too broad a
>question.

I agree it was a broad question. I do have an  implementation 
question:
Why do you use PeekMessage( PM_NOREMOVE) in peek_windows, and not 
GetQueueStatus()? 
PeekMessage() has a side effect: nonqueued messages are sent directly
to the destination procedure. As the application will normally
do a PeekMessage( PM_REMOVE) when returning from select(), it gets the 
message twice. 

Pierre