CODEWITHSUNDEEP
c#
ryeguy
ryeguy

Reputation: 66851

How does this not cause a stack overflow?

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.

Upvotes: 4

Views: 757

Answers (5)

Nick Gunn
Nick Gunn

Reputation: 724

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.

Upvotes: 1

paxdiablo
paxdiablo

Reputation: 881323

ProcessAccept() always calls StartAccept() but the reverse is not true.

In StartAccept(), ProcessAccept() is only called if willRaiseEvent is set to true. That's your exit from the infinite recursion right there.

You always look for the possible exit points if you suspect infinite recursion (in either a single recursive function or one of your ping-pong ones, as you so eloquently put it :-).

Upvotes: 0

Brian
Brian

Reputation: 118865

Hard to determine from the context, but looks like the first only calls the second directly when

Boolean willRaiseEvent = this.listenSocket.AcceptAsync(acceptEventArg);    
if (!willRaiseEvent)    
{

and thus I'm guessing most of the time it raises an event on completion (from a different callback thread)?

(See also the 'stack dive' portion of

http://blogs.msdn.com/mjm/archive/2005/05/04/414793.aspx

which seems to be a similar kind of thing.)

Upvotes: 0

arul
arul

Reputation: 14084

It all depends on the willCauseEvent flag, that when set to true breaks the recursion. That flag is probably set to true in case there's no connection pending.

Upvotes: 0

schnaader
schnaader

Reputation: 49719

Look at the code:

if (!willRaiseEvent)
{
    this.ProcessAccept(acceptEventArg);
}

Although I don't yet understand the whole mechanism, willRaiseEvent == true will clearly end the recursion, so I guess this happens so it's not endless recursion.

Upvotes: 1

Related Questions