In client_acceptor.h, we've extended our object just a bit. The primary reason is to allow us to select the previous single-threaded implementation or our new thread-per-connection implementation. Client_Acceptor itself doesn't use this information but makes it available to the Client_Handler objects it creates. If we wanted a single-strategy implementation, we would have made no changes to the Tutorial 5 version of this file.
// $Id: client_acceptor.h,v 1.1 1998/08/30 13:38:27 jcej Exp $
#ifndef CLIENT_ACCEPTOR_H
#define CLIENT_ACCEPTOR_H
/*
The ACE_Acceptor<> template
lives in the ace/Acceptor.h header file. You'll
find a very consitent naming
convention between the ACE objects and the
headers where they can be
found. In general, the ACE object ACE_Foobar will
be found in ace/Foobar.h.
*/
#include "ace/Acceptor.h"
/*
Since we want to work with
sockets, we'll need a SOCK_Acceptor to allow the
clients to connect to us.
*/
#include "ace/SOCK_Acceptor.h"
/*
The Client_Handler object
we develop will be used to handle clients once
they're connected.
The ACE_Acceptor<> template's first parameter requires
such an object. In
some cases, you can get by with just a forward
declaration on the class,
in others you have to have the whole thing.
*/
#include "client_handler.h"
/*
Parameterize the ACE_Acceptor<>
such that it will listen for socket
connection attempts and create
Client_Handler objects when they happen. In
Tutorial 001, we wrote the
basic acceptor logic on our own before we
realized that ACE_Acceptor<>
was available. You'll get spoiled using the
ACE templates because they
take away a lot of the tedious details!
*/
typedef ACE_Acceptor < Client_Handler,
ACE_SOCK_ACCEPTOR > Client_Acceptor_Base;
/*
Here, we use the parameterized
ACE_Acceptor<> as a baseclass for our customized
Client_Acceptor object.
I've done this so that we can provide it with our choice
of concurrency strategies
when the object is created. Each Client_Handler it
creates will use this information
to determine how to act. If we were going
to create a system that was
always thread-per-connection, we would not have
bothered to extend
Client_Acceptor.
*/
class Client_Acceptor : public Client_Acceptor_Base
{
public:
/*
This is always a good idea. If nothing else, it makes your code more
orthogonal no matter what baseclasses your objects have.
*/
typedef Client_Acceptor_Base inherited;
/*
Construct the object with the concurrency strategy. Since this tutorial
is focused on thread-per-connection, we make that the default. We
could
have chosen to omitt the default and populate it in main() instead.
*/
Client_Acceptor( int _thread_per_connection = 1 )
: thread_per_connection_(_thread_per_connection)
{
}
/*
Return the value of our strategy flag. This is used by the Client_Handler
to decide how to act. If 'true' then the handler will behave in a
thread-per-connection manner.
*/
int thread_per_connection(void)
{ return this->thread_per_connection_; }
protected:
int thread_per_connection_;
};
#endif // CLIENT_ACCEPTOR_H
Ok, so far we haven't done much to change our concurrency strategy. Let's move on to the Client_Handler and see if it has changed any.