Question

I’m looking at the source code for a server using SocketAsyncEventArgs, and I’m trying to figure out how this wouldn’t cause a stack overflow:

So this code is called to allow the socket to accept an incoming connection (scroll down to the bottom to see what I mean):

/// <summary> /// Begins an operation to accept a connection request from the client. /// </summary> /// <param name='acceptEventArg'>The context object to use when issuing  /// the accept operation on the server's listening socket.</param> private void StartAccept(SocketAsyncEventArgs acceptEventArg) {     if (acceptEventArg == null)     {         acceptEventArg = new SocketAsyncEventArgs();         acceptEventArg.Completed += new EventHandler<SocketAsyncEventArgs>(OnAcceptCompleted);     }     else     {         // Socket must be cleared since the context object is being reused.         acceptEventArg.AcceptSocket = null;     }      this.semaphoreAcceptedClients.WaitOne();     Boolean willRaiseEvent = this.listenSocket.AcceptAsync(acceptEventArg);     if (!willRaiseEvent)     {         this.ProcessAccept(acceptEventArg);     } } 

Then this code gets called once a connection is actually accepted (see last line):

  /// <summary>         /// Process the accept for the socket listener.         /// </summary>         /// <param name='e'>SocketAsyncEventArg associated with the completed accept operation.</param>         private void ProcessAccept(SocketAsyncEventArgs e)         {             if (e.BytesTransferred > 0)             {                 Interlocked.Increment(ref this.numConnectedSockets);                 Console.WriteLine('Client connection accepted. There are {0} clients connected to the server',                     this.numConnectedSockets);             }              // Get the socket for the accepted client connection and put it into the              // ReadEventArg object user token.             SocketAsyncEventArgs readEventArgs = this.readWritePool.Pop();             readEventArgs.UserToken = e.AcceptSocket;              // As soon as the client is connected, post a receive to the connection.             Boolean willRaiseEvent = e.AcceptSocket.ReceiveAsync(readEventArgs);             if (!willRaiseEvent)             {                 this.ProcessReceive(readEventArgs);             }              // Accept the next connection request.             this.StartAccept(e); // <==== tail end recursive?         } 

Look at the last line. It calls the top function again. How does this not overflow the stack by ping-ponging back and forth between these 2 functions? It seems to be tail end recursion, but this isn’t Haskell so I don’t see how this would work.

It was my understanding that these weren’t fired in threads but where just executed one at a time by the cpu.

Answer 1

If the AsyncAccept (or any AsyncXXX operation for that matter) cannot be satisfied immediately, then it will return true, indicating that the operation will complete asynchronously. When this happens, the callback-event will ultimately fire on a thread-pool thread. Even if it marshal’s back to a UI thread (because it was initiated there), it will do so via a post.

AsyncAccept is highly likely to return true, because unless there are socket connections truly pending (see backlog in Listen), you are waiting for a client to connect.

Hence, StartAccept() will simply exit without calling ProcessAccept, and ProcessAccept when (and if) it fires, will probably be on a different thread.