diff options
Diffstat (limited to 'docs/tutorials')
31 files changed, 394 insertions, 282 deletions
diff --git a/docs/tutorials/001/acceptor.h b/docs/tutorials/001/acceptor.h index 988b1948231..094e68acdf5 100644 --- a/docs/tutorials/001/acceptor.h +++ b/docs/tutorials/001/acceptor.h @@ -2,7 +2,7 @@ // $Id$ -#if !defined (_CLIENT_ACCEPTOR_H) +#ifndef _CLIENT_ACCEPTOR_H #define _CLIENT_ACCEPTOR_H /* @@ -11,6 +11,10 @@ */ #include "ace/SOCK_Acceptor.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* An Event_Handler is what you register with ACE_Reactor. When events occur, the reactor will callback on the Event_Handler. More on that in a few lines. @@ -72,7 +76,7 @@ public: */ return _reactor->register_handler( this, ACE_Event_Handler::ACCEPT_MASK ); } - + private: /* @@ -84,8 +88,8 @@ private: acceptor object, so that's what we provide. */ ACE_HANDLE get_handle (void) const - { - return this->peer_acceptor_.get_handle (); + { + return this->peer_acceptor_.get_handle (); } /* @@ -100,7 +104,7 @@ private: disconnects. */ Logging_Handler *svc_handler = new Logging_Handler; - + /* To complete the connection, we invoke the accept() method call on the acceptor object and provide it with the connection handler instance. @@ -117,7 +121,7 @@ private: */ if (svc_handler->open (reactor_) == -1) svc_handler->close (); - + return 0; } @@ -126,7 +130,7 @@ protected: /* Our acceptor object instance */ - ACE_SOCK_Acceptor peer_acceptor_; + ACE_SOCK_Acceptor peer_acceptor_; /* A place to remember our reactor pointer diff --git a/docs/tutorials/001/logger.h b/docs/tutorials/001/logger.h index 8063f83f48a..6e46176fd6e 100644 --- a/docs/tutorials/001/logger.h +++ b/docs/tutorials/001/logger.h @@ -2,7 +2,7 @@ // $Id$ -#if !defined (_CLIENT_HANDLER_H) +#ifndef _CLIENT_HANDLER_H #define _CLIENT_HANDLER_H /* @@ -11,6 +11,10 @@ */ #include "ace/Event_Handler.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/INET_Addr.h" /* @@ -92,7 +96,7 @@ protected: */ char buf[128]; memset(buf,0,sizeof(buf)); - + /* Invoke the recv() method of the ACE_SOCK_Stream to get some data. It will return -1 if there is an error. Otherwise, it will return the number of bytes @@ -114,7 +118,7 @@ protected: default: ACE_DEBUG ((LM_DEBUG, "(%P|%t) from client: %s",buf)); } - + return 0; } @@ -139,7 +143,7 @@ protected: Since we know we were dynamically allocated by the acceptor, now is a good time to get rid of ourselves. */ - delete this; + delete this; return 0; } @@ -149,7 +153,7 @@ protected: /* Our peer connection. */ - ACE_SOCK_Stream cli_stream_; + ACE_SOCK_Stream cli_stream_; /* Our reactor (and our acceptor's reactor). diff --git a/docs/tutorials/002/handler.h b/docs/tutorials/002/handler.h index e7796cbb47b..a66ccccb9e6 100644 --- a/docs/tutorials/002/handler.h +++ b/docs/tutorials/002/handler.h @@ -5,6 +5,11 @@ #define LOGGING_HANDLER_H #include "ace/INET_Addr.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/SOCK_Stream.h" #include "ace/Reactor.h" diff --git a/docs/tutorials/005/client_acceptor.h b/docs/tutorials/005/client_acceptor.h index 82416fa999c..fa3d3b41be8 100644 --- a/docs/tutorials/005/client_acceptor.h +++ b/docs/tutorials/005/client_acceptor.h @@ -7,17 +7,21 @@ /* 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 + headers where they can be found. In general, the ACE object ACE_Foobar will - be found in ace/Foobar.h. + be found in ace/Foobar.h. */ #include "ace/Acceptor.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* Since we want to work with sockets, we'll need a SOCK_Acceptor to allow the - clients to connect to us. + clients to connect to us. */ #include "ace/SOCK_Acceptor.h" @@ -25,7 +29,7 @@ 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. + declaration on the class, in others you have to have the whole thing. */ #include "client_handler.h" @@ -34,7 +38,7 @@ 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! + ACE templates because they take away a lot of the tedious details! */ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor; diff --git a/docs/tutorials/005/client_handler.h b/docs/tutorials/005/client_handler.h index bdd8d903f6f..b1e4af021d3 100644 --- a/docs/tutorials/005/client_handler.h +++ b/docs/tutorials/005/client_handler.h @@ -8,22 +8,27 @@ Our client handler must exist somewhere in the ACE_Event_Handler object hierarchy. This is a requirement of the ACE_Reactor because it maintains ACE_Event_Handler pointers for each registered event handler. You could - derive our Client_Handler directly from ACE_Event_Handler but you still have + derive our Client_Handler directly from ACE_Event_Handler but you still have to have an ACE_SOCK_Stream for the actually connection. With a direct derivative of ACE_Event_Handler, you'll have to contain and maintain an ACE_SOCK_Stream instance yourself. With ACE_Svc_Handler (which is a derivative of ACE_Event_Handler) some of those details are handled for you. - + */ #include "ace/Svc_Handler.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/SOCK_Stream.h" /* - Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> + Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> interface as well. That's what the ACE_NULL_SYNCH parameter below is all about. That's beyond our scope here but we'll come back to it in the next - tutorial when we start looking at concurrency options. + tutorial when we start looking at concurrency options. */ class Client_Handler : public ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH > { @@ -38,20 +43,20 @@ public: intuitive (at least to me). Instead, we provide a new method of destruction and we make our destructor protected so that only ourselves, our derivatives and our friends can delete us. It's a nice - compromise. + compromise. */ void destroy (void); /* Most ACE objects have an open() method. That's how you make them ready - to do work. ACE_Event_Handler has a virtual open() method which allows us + to do work. ACE_Event_Handler has a virtual open() method which allows us to create this overrride. ACE_Acceptor<> will invoke this method after creating a new Client_Handler when a client connects. Notice that the parameter to open() is a void*. It just so happens that the pointer - points to the acceptor which created us. You would like for the parameter + points to the acceptor which created us. You would like for the parameter to be an ACE_Acceptor<>* but since ACE_Event_Handler is generic, that would tie it too closely to the ACE_Acceptor<> set of objects. In our - definition of open() you'll see how we get around that. + definition of open() you'll see how we get around that. */ int open (void *_acceptor); @@ -62,8 +67,8 @@ public: clean itself up. Since an event handler can be registered for more than one type of callback, the callback mask is provided to inform handle_close() exactly which method failed. That way, you don't have to - maintain state information between your handle_* method calls. The _handle - parameter is explained below... + maintain state information between your handle_* method calls. The _handle + parameter is explained below... */ int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask); @@ -78,7 +83,7 @@ protected: maintains it's own peer (ACE_SOCK_Stream) object, this is redundant for us. However, if we had been derived directly from ACE_Event_Handler, we may have chosen not to contain the peer. In that case, the _handleg - would be important to us for reading the client's data. + would be important to us for reading the client's data. */ int handle_input (ACE_HANDLE _handle); @@ -87,15 +92,15 @@ protected: function which I will call from handle_input(). That allows me to introduce concurrencly in later tutorials with a no changes to the worker function. You can think of process() as application-level code and - everything elase as application-framework code. + everything elase as application-framework code. */ int process (char *_rdbuf, int _rdbuf_len); /* We don't really do anything in our destructor but we've declared it to be protected to prevent casual deletion of this object. As I said above, I - really would prefer that everyone goes through the destroy() method to get - rid of us. + really would prefer that everyone goes through the destroy() method to get + rid of us. */ ~Client_Handler (void); }; diff --git a/docs/tutorials/006/client_acceptor.h b/docs/tutorials/006/client_acceptor.h index b0944f3a316..2318b6adacd 100644 --- a/docs/tutorials/006/client_acceptor.h +++ b/docs/tutorials/006/client_acceptor.h @@ -7,17 +7,21 @@ /* 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 + headers where they can be found. In general, the ACE object ACE_Foobar will - be found in ace/Foobar.h. + be found in ace/Foobar.h. */ #include "ace/Acceptor.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* Since we want to work with sockets, we'll need a SOCK_Acceptor to allow the - clients to connect to us. + clients to connect to us. */ #include "ace/SOCK_Acceptor.h" @@ -25,7 +29,7 @@ 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. + declaration on the class, in others you have to have the whole thing. */ #include "client_handler.h" @@ -34,7 +38,7 @@ 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! + ACE templates because they take away a lot of the tedious details! */ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base; @@ -49,32 +53,32 @@ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base; 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_; } + /* + 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_; + int thread_per_connection_; }; diff --git a/docs/tutorials/006/client_handler.h b/docs/tutorials/006/client_handler.h index d80c23e942d..83a4c326b94 100644 --- a/docs/tutorials/006/client_handler.h +++ b/docs/tutorials/006/client_handler.h @@ -8,19 +8,24 @@ Our client handler must exist somewhere in the ACE_Event_Handler object hierarchy. This is a requirement of the ACE_Reactor because it maintains ACE_Event_Handler pointers for each registered event handler. You could - derive our Client_Handler directly from ACE_Event_Handler but you still have + derive our Client_Handler directly from ACE_Event_Handler but you still have to have an ACE_SOCK_Stream for the actually connection. With a direct derivative of ACE_Event_Handler, you'll have to contain and maintain an ACE_SOCK_Stream instance yourself. With ACE_Svc_Handler (which is a derivative of ACE_Event_Handler) some of those details are handled for you. - + */ #include "ace/Svc_Handler.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/SOCK_Stream.h" /* - Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> + Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> interface as well. That's what the ACE_NULL_SYNCH parameter below is all about. If our Client_Acceptor has chosen thread-per-connection then our open() method will activate us into a thread. At that point, our svc() @@ -42,27 +47,27 @@ public: intuitive (at least to me). Instead, we provide a new method of destruction and we make our destructor protected so that only ourselves, our derivatives and our friends can delete us. It's a nice - compromise. + compromise. */ void destroy (void); /* Most ACE objects have an open() method. That's how you make them ready - to do work. ACE_Event_Handler has a virtual open() method which allows us + to do work. ACE_Event_Handler has a virtual open() method which allows us to create this overrride. ACE_Acceptor<> will invoke this method after creating a new Client_Handler when a client connects. Notice that the parameter to open() is a void*. It just so happens that the pointer - points to the acceptor which created us. You would like for the parameter + points to the acceptor which created us. You would like for the parameter to be an ACE_Acceptor<>* but since ACE_Event_Handler is generic, that would tie it too closely to the ACE_Acceptor<> set of objects. In our - definition of open() you'll see how we get around that. + definition of open() you'll see how we get around that. */ int open (void *_acceptor); /* When an ACE_Task<> object falls out of the svc() method, the framework - will call the close() method. That's where we want to cleanup ourselves - if we're running in either thread-per-connection or thread-pool mode. + will call the close() method. That's where we want to cleanup ourselves + if we're running in either thread-per-connection or thread-pool mode. */ int close(u_long flags = 0); @@ -73,8 +78,8 @@ public: clean itself up. Since an event handler can be registered for more than one type of callback, the callback mask is provided to inform handle_close() exactly which method failed. That way, you don't have to - maintain state information between your handle_* method calls. The _handle - parameter is explained below... + maintain state information between your handle_* method calls. The _handle + parameter is explained below... */ int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask); @@ -97,7 +102,7 @@ protected: maintains it's own peer (ACE_SOCK_Stream) object, this is redundant for us. However, if we had been derived directly from ACE_Event_Handler, we may have chosen not to contain the peer. In that case, the _handleg - would be important to us for reading the client's data. + would be important to us for reading the client's data. */ int handle_input (ACE_HANDLE _handle); @@ -112,8 +117,8 @@ protected: /* We don't really do anything in our destructor but we've declared it to be protected to prevent casual deletion of this object. As I said above, I - really would prefer that everyone goes through the destroy() method to get - rid of us. + really would prefer that everyone goes through the destroy() method to get + rid of us. */ ~Client_Handler (void); }; diff --git a/docs/tutorials/007/client_acceptor.h b/docs/tutorials/007/client_acceptor.h index e1c0eded6fd..82c761879ea 100644 --- a/docs/tutorials/007/client_acceptor.h +++ b/docs/tutorials/007/client_acceptor.h @@ -7,15 +7,19 @@ /* 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. + headers where they can be found. In general, the ACE object ACE_Foobar will + be found in ace/Foobar.h. */ #include "ace/Acceptor.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* Since we want to work with sockets, we'll need a SOCK_Acceptor to allow the - clients to connect to us. + clients to connect to us. */ #include "ace/SOCK_Acceptor.h" @@ -23,7 +27,7 @@ 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. + declaration on the class, in others you have to have the whole thing. */ #include "client_handler.h" @@ -32,7 +36,7 @@ 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! + ACE templates because they take away a lot of the tedious details! */ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base; @@ -57,81 +61,81 @@ typedef ACE_Acceptor < Client_Handler, ACE_SOCK_ACCEPTOR > Client_Acceptor_Base; class Client_Acceptor : public Client_Acceptor_Base { public: - typedef Client_Acceptor_Base inherited; - - /* - Now that we have more than two strategies, we need more than a boolean - to tell us what we're using. A set of enums is a good choice because - it allows us to use named values. Another option would be a set of - static const integers. - */ - enum concurrency_t - { - single_threaded_, - thread_per_connection_, - thread_pool_ - }; - - /* - The default constructor allows the programmer to choose the concurrency - strategy. Since we want to focus on thread-pool, that's what we'll use - if nothing is specified. - */ - Client_Acceptor( int _concurrency = thread_pool_ ); - - /* - Another option is to construct the object with an existing thread pool. - The concurrency strategy is pretty obvious at that point. - */ - Client_Acceptor( Thread_Pool & _thread_pool ); - - /* - Our destructor will take care of shutting down the thread-pool - if applicable. - */ - ~Client_Acceptor( void ); - - /* - Open ourselves and register with the given reactor. The thread pool size - can be specified here if you want to use that concurrency strategy. - */ - int open( const ACE_INET_Addr & _addr, ACE_Reactor * _reactor, - int _pool_size = Thread_Pool::default_pool_size_ ); - - /* - Close ourselves and our thread pool if applicable - */ - int close(void); - - /* - What is our concurrency strategy? - */ - int concurrency(void) - { return this->concurrency_; } - - /* - Give back a pointer to our thread pool. Our Client_Handler objects - will need this so that their handle_input() methods can put themselves - into the pool. Another alternative would be a globally accessible - thread pool. ACE_Singleton<> is a way to achieve that. - */ - Thread_Pool * thread_pool(void) - { return & this->the_thread_pool_; } - - /* - Since we can be constructed with a Thread_Pool reference, there are times - when we need to know if the thread pool we're using is ours or if we're - just borrowing it from somebody else. - */ - int thread_pool_is_private(void) - { return &the_thread_pool_ == &private_thread_pool_; } + typedef Client_Acceptor_Base inherited; + + /* + Now that we have more than two strategies, we need more than a boolean + to tell us what we're using. A set of enums is a good choice because + it allows us to use named values. Another option would be a set of + static const integers. + */ + enum concurrency_t + { + single_threaded_, + thread_per_connection_, + thread_pool_ + }; + + /* + The default constructor allows the programmer to choose the concurrency + strategy. Since we want to focus on thread-pool, that's what we'll use + if nothing is specified. + */ + Client_Acceptor( int _concurrency = thread_pool_ ); + + /* + Another option is to construct the object with an existing thread pool. + The concurrency strategy is pretty obvious at that point. + */ + Client_Acceptor( Thread_Pool & _thread_pool ); + + /* + Our destructor will take care of shutting down the thread-pool + if applicable. + */ + ~Client_Acceptor( void ); + + /* + Open ourselves and register with the given reactor. The thread pool size + can be specified here if you want to use that concurrency strategy. + */ + int open( const ACE_INET_Addr & _addr, ACE_Reactor * _reactor, + int _pool_size = Thread_Pool::default_pool_size_ ); + + /* + Close ourselves and our thread pool if applicable + */ + int close(void); + + /* + What is our concurrency strategy? + */ + int concurrency(void) + { return this->concurrency_; } + + /* + Give back a pointer to our thread pool. Our Client_Handler objects + will need this so that their handle_input() methods can put themselves + into the pool. Another alternative would be a globally accessible + thread pool. ACE_Singleton<> is a way to achieve that. + */ + Thread_Pool * thread_pool(void) + { return & this->the_thread_pool_; } + + /* + Since we can be constructed with a Thread_Pool reference, there are times + when we need to know if the thread pool we're using is ours or if we're + just borrowing it from somebody else. + */ + int thread_pool_is_private(void) + { return &the_thread_pool_ == &private_thread_pool_; } protected: - int concurrency_; + int concurrency_; - Thread_Pool private_thread_pool_; + Thread_Pool private_thread_pool_; - Thread_Pool & the_thread_pool_; + Thread_Pool & the_thread_pool_; }; #endif // CLIENT_ACCEPTOR_H diff --git a/docs/tutorials/007/client_handler.h b/docs/tutorials/007/client_handler.h index 340cde65a4d..57fd5e033d2 100644 --- a/docs/tutorials/007/client_handler.h +++ b/docs/tutorials/007/client_handler.h @@ -8,7 +8,7 @@ Our client handler must exist somewhere in the ACE_Event_Handler object hierarchy. This is a requirement of the ACE_Reactor because it maintains ACE_Event_Handler pointers for each registered event handler. You could - derive our Client_Handler directly from ACE_Event_Handler but you still have + derive our Client_Handler directly from ACE_Event_Handler but you still have to have an ACE_SOCK_Stream for the actually connection. With a direct derivative of ACE_Event_Handler, you'll have to contain and maintain an ACE_SOCK_Stream instance yourself. With ACE_Svc_Handler (which is a @@ -16,16 +16,21 @@ */ #include "ace/Svc_Handler.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/SOCK_Stream.h" class Client_Acceptor; class Thread_Pool; /* - Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> + Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> interface as well. That's what the ACE_NULL_SYNCH parameter below is all about. That's beyond our scope here but we'll come back to it in the next - tutorial when we start looking at concurrency options. + tutorial when we start looking at concurrency options. */ class Client_Handler : public ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH > { @@ -41,27 +46,27 @@ public: intuitive (at least to me). Instead, we provide a new method of destruction and we make our destructor protected so that only ourselves, our derivatives and our friends can delete us. It's a nice - compromise. + compromise. */ void destroy (void); /* Most ACE objects have an open() method. That's how you make them ready - to do work. ACE_Event_Handler has a virtual open() method which allows us + to do work. ACE_Event_Handler has a virtual open() method which allows us to create this overrride. ACE_Acceptor<> will invoke this method after creating a new Client_Handler when a client connects. Notice that the parameter to open() is a void*. It just so happens that the pointer - points to the acceptor which created us. You would like for the parameter + points to the acceptor which created us. You would like for the parameter to be an ACE_Acceptor<>* but since ACE_Event_Handler is generic, that would tie it too closely to the ACE_Acceptor<> set of objects. In our - definition of open() you'll see how we get around that. + definition of open() you'll see how we get around that. */ int open (void *_acceptor); /* When an ACE_Task<> object falls out of the svc() method, the framework - will call the close() method. That's where we want to cleanup ourselves - if we're running in either thread-per-connection or thread-pool mode. + will call the close() method. That's where we want to cleanup ourselves + if we're running in either thread-per-connection or thread-pool mode. */ int close(u_long flags = 0); @@ -72,8 +77,8 @@ public: clean itself up. Since an event handler can be registered for more than one type of callback, the callback mask is provided to inform handle_close() exactly which method failed. That way, you don't have to - maintain state information between your handle_* method calls. The _handle - parameter is explained below... + maintain state information between your handle_* method calls. The _handle + parameter is explained below... */ int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask); @@ -86,7 +91,7 @@ public: maintains it's own peer (ACE_SOCK_Stream) object, this is redundant for us. However, if we had been derived directly from ACE_Event_Handler, we may have chosen not to contain the peer. In that case, the _handleg - would be important to us for reading the client's data. + would be important to us for reading the client's data. */ int handle_input (ACE_HANDLE _handle); @@ -105,39 +110,39 @@ protected: function which I will call from handle_input(). That allows me to introduce concurrencly in later tutorials with a no changes to the worker function. You can think of process() as application-level code and - everything elase as application-framework code. + everything elase as application-framework code. */ int process (char *_rdbuf, int _rdbuf_len); /* We don't really do anything in our destructor but we've declared it to be protected to prevent casual deletion of this object. As I said above, I - really would prefer that everyone goes through the destroy() method to get - rid of us. + really would prefer that everyone goes through the destroy() method to get + rid of us. */ ~Client_Handler (void); /* When we get to the definition of Client_Handler we'll see that there are - several places where we go back to the Client_Acceptor for information. - It is generally a good idea to do that through an accesor rather than - using the member variable directly. + several places where we go back to the Client_Acceptor for information. + It is generally a good idea to do that through an accesor rather than + using the member variable directly. */ Client_Acceptor * client_acceptor( void ) - { return this->client_acceptor_; } + { return this->client_acceptor_; } /* And since you shouldn't access a member variable directly, neither should you - set (mutate) it. Although it might seem silly to do it this way, you'll thank - yourself for it later. + set (mutate) it. Although it might seem silly to do it this way, you'll thank + yourself for it later. */ void client_acceptor( Client_Acceptor * _client_acceptor ) - { this->client_acceptor_ = _client_acceptor; } + { this->client_acceptor_ = _client_acceptor; } /* The concurrency() accessor tells us the current concurrency strategy. It actually - queries the Client_Acceptor for it but by having the accessor in place, we could - change our implementation without affecting everything that needs to know. + queries the Client_Acceptor for it but by having the accessor in place, we could + change our implementation without affecting everything that needs to know. */ int concurrency(void); @@ -151,12 +156,12 @@ protected: /* For some reason I didn't create accessor/mutator methods for this. So much for - consistency.... + consistency.... - This variable is used to remember the thread in which we were created: the "creator" - thread in other words. handle_input() needs to know if it is operating in the - main reactor thread (which is the one that created us) or if it is operating in - one of the thread pool threads. More on this when we get to handle_input(). + This variable is used to remember the thread in which we were created: the "creator" + thread in other words. handle_input() needs to know if it is operating in the + main reactor thread (which is the one that created us) or if it is operating in + one of the thread pool threads. More on this when we get to handle_input(). */ ACE_thread_t creator_; }; diff --git a/docs/tutorials/007/thread_pool.h b/docs/tutorials/007/thread_pool.h index ebf2e162ce4..0897b1d47af 100644 --- a/docs/tutorials/007/thread_pool.h +++ b/docs/tutorials/007/thread_pool.h @@ -10,6 +10,10 @@ */ #include "ace/Task.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* We need a forward reference for ACE_Event_Handler so that our enqueue() method can accept a pointer to one. @@ -29,38 +33,38 @@ public: typedef ACE_Task<ACE_MT_SYNCH> inherited; - /* - Provide an enumeration for the default pool size. By doing this, other objects - can use the value when they want a default. - */ - enum size_t - { - default_pool_size_ = 5 - }; + /* + Provide an enumeration for the default pool size. By doing this, other objects + can use the value when they want a default. + */ + enum size_t + { + default_pool_size_ = 5 + }; - // Basic constructor - Thread_Pool(void); + // Basic constructor + Thread_Pool(void); - /* - Opening the thread pool causes one or more threads to be activated. When activated, - they all execute the svc() method declared below. - */ - int open( int _pool_size = default_pool_size_ ); + /* + Opening the thread pool causes one or more threads to be activated. When activated, + they all execute the svc() method declared below. + */ + int open( int _pool_size = default_pool_size_ ); /* Some compilers will complain that our open() above attempts to override a virtual function in the baseclass. We have no intention of overriding that method but in order to keep the - compiler quiet we have to add this method as a pass-thru to the + compiler quiet we have to add this method as a pass-thru to the baseclass method. */ - virtual int open(void * _void_data) - { return inherited::open(_void_data); } + virtual int open(void * _void_data) + { return inherited::open(_void_data); } - /* - When you're done wit the thread pool, you have to have some way to shut it down. - This is what close() is for. - */ + /* + When you're done wit the thread pool, you have to have some way to shut it down. + This is what close() is for. + */ int close( void ); /* @@ -70,38 +74,38 @@ public: virtual int close( u_long flags ) { return inherited::close(flags); } - /* - To use the thread pool, you have to put some unit of work into it. Since we're - dealing with event handlers (or at least their derivatives), I've chosen to provide - an enqueue() method that takes a pointer to an ACE_Event_Handler. The handler's - handle_input() method will be called, so your object has to know when it is being - called by the thread pool. - */ - int enqueue( ACE_Event_Handler * _handler ); - - /* - Another handy ACE template is ACE_Atomic_Op<>. When parameterized, this allows - is to have a thread-safe counting object. The typical arithmetic operators are - all internally thread-safe so that you can share it across threads without worrying - about any contention issues. - */ - typedef ACE_Atomic_Op<ACE_Mutex,int> counter_t; + /* + To use the thread pool, you have to put some unit of work into it. Since we're + dealing with event handlers (or at least their derivatives), I've chosen to provide + an enqueue() method that takes a pointer to an ACE_Event_Handler. The handler's + handle_input() method will be called, so your object has to know when it is being + called by the thread pool. + */ + int enqueue( ACE_Event_Handler * _handler ); + + /* + Another handy ACE template is ACE_Atomic_Op<>. When parameterized, this allows + is to have a thread-safe counting object. The typical arithmetic operators are + all internally thread-safe so that you can share it across threads without worrying + about any contention issues. + */ + typedef ACE_Atomic_Op<ACE_Mutex,int> counter_t; protected: - /* - Our svc() method will dequeue the enqueued event handler objects and invoke the - handle_input() method on each. Since we're likely running in more than one thread, - idle threads can take work from the queue while other threads are busy executing - handle_input() on some object. - */ - int svc(void); - - /* - We use the atomic op to keep a count of the number of threads in which our svc() - method is running. This is particularly important when we want to close() it down! - */ - counter_t active_threads_; + /* + Our svc() method will dequeue the enqueued event handler objects and invoke the + handle_input() method on each. Since we're likely running in more than one thread, + idle threads can take work from the queue while other threads are busy executing + handle_input() on some object. + */ + int svc(void); + + /* + We use the atomic op to keep a count of the number of threads in which our svc() + method is running. This is particularly important when we want to close() it down! + */ + counter_t active_threads_; }; #endif // THREAD_POOL_H diff --git a/docs/tutorials/010/block.h b/docs/tutorials/010/block.h index 662c3c1e536..583886872cb 100644 --- a/docs/tutorials/010/block.h +++ b/docs/tutorials/010/block.h @@ -6,8 +6,12 @@ #include "ace/Message_Block.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* - This simple ACE_Message_Block derivative will inform us of it's construction + This simple ACE_Message_Block derivative will inform us of it's construction and destruction. We'll use this to assure ourselves that we don't have any memory leaks. In a real application, of course, this isn't necessary. */ diff --git a/docs/tutorials/010/task.h b/docs/tutorials/010/task.h index 9f242c124dd..2aecb429c03 100644 --- a/docs/tutorials/010/task.h +++ b/docs/tutorials/010/task.h @@ -6,6 +6,10 @@ #include "ace/Task.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* Like the thread-pool server tutorial, we'll derive from ACE_Task<>. Our goal here is to show off the ACE_Message_Queue and the best way @@ -17,7 +21,7 @@ class Task : public ACE_Task < ACE_MT_SYNCH > public: typedef ACE_Task < ACE_MT_SYNCH > inherited; - + /* The constructor/destructor are simple but take care of some necessary housekeeping. diff --git a/docs/tutorials/011/block.h b/docs/tutorials/011/block.h index bfd49d723f7..1ffc5cb4e9d 100644 --- a/docs/tutorials/011/block.h +++ b/docs/tutorials/011/block.h @@ -6,6 +6,10 @@ #include "ace/Message_Block.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + class Block : public ACE_Message_Block { public: diff --git a/docs/tutorials/011/task.h b/docs/tutorials/011/task.h index 436326c68a0..8646fac1a7c 100644 --- a/docs/tutorials/011/task.h +++ b/docs/tutorials/011/task.h @@ -6,6 +6,10 @@ #include "ace/Task.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + class Task : public ACE_Task < ACE_MT_SYNCH > { public: diff --git a/docs/tutorials/012/data.h b/docs/tutorials/012/data.h index 3c656608425..54e8e55e87c 100644 --- a/docs/tutorials/012/data.h +++ b/docs/tutorials/012/data.h @@ -6,6 +6,10 @@ #include "ace/Message_Block.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* We'll start by defining a basic unit of work that can be put into the message queue. The threads in the pool will expect to find one @@ -71,8 +75,8 @@ protected: /* We derive a Message_Block from ACE_Message_Block and teach it about - our Unit_Of_Work object. When our task's svc() method pulls a block - out of the queue, it can then invoke the virtual methods of the work + our Unit_Of_Work object. When our task's svc() method pulls a block + out of the queue, it can then invoke the virtual methods of the work object safely. In this implementation we've also retained the original ACE_Message_Block functionallity so that we can use the underlying ACE_Data_Block objects to store data other than our @@ -96,7 +100,7 @@ public: ACE_DEBUG ((LM_DEBUG, "(%P|%t) Message_Block ctor 0x%x for 0x%x\n", (void *) this, data_)); } - ~Message_Block(void) + ~Message_Block(void) { ACE_DEBUG ((LM_DEBUG, "(%P|%t) Message_Block dtor 0x%x for 0x%x\n", (void *) this, data_)); delete data_; diff --git a/docs/tutorials/012/task.h b/docs/tutorials/012/task.h index 52dcf022b3e..877ac98ede5 100644 --- a/docs/tutorials/012/task.h +++ b/docs/tutorials/012/task.h @@ -6,6 +6,10 @@ #include "ace/Task.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* This is our basic thread-pool Task. We have a choice of pool size on the open() and the usual svc() and close() methods. diff --git a/docs/tutorials/013/block.h b/docs/tutorials/013/block.h index 40a31bd1b07..26604a57e4c 100644 --- a/docs/tutorials/013/block.h +++ b/docs/tutorials/013/block.h @@ -5,6 +5,11 @@ #define BLOCK_H #include "ace/Message_Block.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/Synch.h" #include "mld.h" #include "work.h" @@ -16,7 +21,7 @@ out of scope unexpectedly. An ACE_Message_Block will be deleted as soon as it's release() method is called but the ACE_Data_Blocks it uses are reference counted and only delete when the last reference release()es the - block. We use that trait to simply our object memory management. + block. We use that trait to simply our object memory management. */ class Data_Block : public ACE_Data_Block { @@ -49,9 +54,9 @@ public: ~Lock (void); // When the Data_Block is destroyed, the Message_Block is - // holding a lock with this object. If we were to destroy + // holding a lock with this object. If we were to destroy // the Lock with the Data_Block, we would have a - // segfault. Instead, the Data_Block invokes destroy() to + // segfault. Instead, the Data_Block invokes destroy() to // mark the object as un-needed so that when the // Message_Block invokes release() to drop the lock, the // Lock can delete itself. @@ -65,7 +70,7 @@ protected: /* This simple derivative of ACE_Message_Block will construct our Data_Block - object to contain a unit of work. + object to contain a unit of work. */ class Message_Block : public ACE_Message_Block { diff --git a/docs/tutorials/013/mld.h b/docs/tutorials/013/mld.h index a9ee1de02b4..7dbd982e863 100644 --- a/docs/tutorials/013/mld.h +++ b/docs/tutorials/013/mld.h @@ -5,13 +5,18 @@ #define MLD_H #include "ace/Synch.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/Singleton.h" /* This is a cheap memory leak detector. Each class I want to watch over contains an mld object. The mld object's ctor increments a global counter while the dtor decrements it. If the counter is non-zero when the program - is ready to exit then there may be a leak. + is ready to exit then there may be a leak. */ class mld @@ -30,12 +35,12 @@ protected: /* Just drop 'MLD' anywhere in your class definition to get cheap memory leak - detection for your class. + detection for your class. */ #define MLD mld mld_ /* - Use 'MLD_COUNTER' in main() to see if things are OK. + Use 'MLD_COUNTER' in main() to see if things are OK. */ #define MLD_COUNTER mld::value() diff --git a/docs/tutorials/013/task.h b/docs/tutorials/013/task.h index 0c813641169..8c11a8872c6 100644 --- a/docs/tutorials/013/task.h +++ b/docs/tutorials/013/task.h @@ -5,15 +5,20 @@ #define TASK_H #include "ace/Task.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "mld.h" /* - This is much like the Task we've used in the past for implementing a thread - pool. This time, however, I've made the Task an element in a singly-linked + This is much like the Task we've used in the past for implementing a thread + pool. This time, however, I've made the Task an element in a singly-linked list. As the svc() method finishes the process() on a unit of work, it will enqueue that unit of work to the next_ Task if there is one. If the Task does not have a next_ Task, it will invoke the unit of work object's - fini() method after invoking process(). + fini() method after invoking process(). */ class Task : public ACE_Task < ACE_MT_SYNCH > { diff --git a/docs/tutorials/013/work.h b/docs/tutorials/013/work.h index 26e10b96266..0cf60afd1ed 100644 --- a/docs/tutorials/013/work.h +++ b/docs/tutorials/013/work.h @@ -5,12 +5,17 @@ #define WORK_H #include "ace/Log_Msg.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/Synch.h" #include "mld.h" /* Our specilized message queue and thread pool will know how to do "work" on - our Unit_Of_Work baseclass. + our Unit_Of_Work baseclass. */ class Unit_Of_Work { @@ -42,7 +47,7 @@ protected: /* A fairly trivial work derivative that implements an equally trivial state - machine in process() + machine in process() */ class Work : public Unit_Of_Work { diff --git a/docs/tutorials/014/EndTask.h b/docs/tutorials/014/EndTask.h index e4ab823f1f9..1666c5e8869 100644 --- a/docs/tutorials/014/EndTask.h +++ b/docs/tutorials/014/EndTask.h @@ -22,9 +22,9 @@ // your first module, and a Stream_Tail behind your // last module. // -// If your put() a message to the Stream Tail, it +// If your put() a message to the Stream Tail, it // assumes you did so in error. This simple EndTask -// class allows you to push a message to it and just +// class allows you to push a message to it and just // have it safely Go Away. // // All this Task does is release the Message_Block @@ -39,33 +39,33 @@ public: typedef Task inherited; EndTask(const char *nameOfTask) : - inherited(nameOfTask, 0) { + inherited(nameOfTask, 0) { // when we get open()'d, it with 0 threads // since there is actually no processing to do. - cerr << __LINE__ << " " << __FILE__ << endl; + cerr << __LINE__ << " " << __FILE__ << endl; }; virtual int open(void *) { - cerr << __LINE__ << " " << __FILE__ << endl; - return 0; + cerr << __LINE__ << " " << __FILE__ << endl; + return 0; } virtual int open(void) { - cerr << __LINE__ << " " << __FILE__ << endl; - return 0; + cerr << __LINE__ << " " << __FILE__ << endl; + return 0; } virtual ~EndTask(void) { }; virtual int put(ACE_Message_Block *message, - ACE_Time_Value *timeout) { + ACE_Time_Value *timeout) { - cerr << __LINE__ << " " << __FILE__ << endl; + cerr << __LINE__ << " " << __FILE__ << endl; ACE_UNUSED_ARG(timeout); // we don't have anything to do, so diff --git a/docs/tutorials/014/Task.h b/docs/tutorials/014/Task.h index e4797f49892..adb533c01ef 100644 --- a/docs/tutorials/014/Task.h +++ b/docs/tutorials/014/Task.h @@ -42,8 +42,8 @@ public: // This closes down the Task and all service threads. virtual int put(ACE_Message_Block *message, - ACE_Time_Value *timeout); - // This is the interface that ACE_Stream uses to + ACE_Time_Value *timeout); + // This is the interface that ACE_Stream uses to // communicate with our Task. virtual int svc(void); diff --git a/docs/tutorials/015/Client.h b/docs/tutorials/015/Client.h index 63d22b03f73..c9f4e496bf2 100644 --- a/docs/tutorials/015/Client.h +++ b/docs/tutorials/015/Client.h @@ -5,6 +5,11 @@ #define CLIENT_H #include "ace/SOCK_Stream.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "Protocol_Stream.h" class ACE_Message_Block; @@ -41,11 +46,11 @@ public: int get( ACE_Message_Block * & _response ); private: - // Protocol_Stream hides the protocol conformance details from + // Protocol_Stream hides the protocol conformance details from // us. Protocol_Stream stream_; - // We create a connection on the peer_ and then pass ownership + // We create a connection on the peer_ and then pass ownership // of it to the protocol stream. ACE_SOCK_Stream peer_; @@ -54,7 +59,7 @@ private: const char * server_; // Accessors for the complex member variables. - + Protocol_Stream & stream(void) { return this->stream_; diff --git a/docs/tutorials/015/Compressor.h b/docs/tutorials/015/Compressor.h index bc0257b16d1..4aaa83144ed 100644 --- a/docs/tutorials/015/Compressor.h +++ b/docs/tutorials/015/Compressor.h @@ -12,18 +12,18 @@ class Compressor : public Protocol_Task { public: - + typedef Protocol_Task inherited; // I've given you the option of creating this task derivative - // with a number of threads. In retro-spect that really isn't + // with a number of threads. In retro-spect that really isn't // a good idea. Most client/server systems rely on requests - // and responses happening in a predicatable order. Introduce + // and responses happening in a predicatable order. Introduce // a thread pool and message queue and that ordering goes // right out the window. In other words: Don't ever use the // constructor parameter! Compressor( int _thr_count = 0 ); - + ~Compressor(void); protected: diff --git a/docs/tutorials/015/Crypt.h b/docs/tutorials/015/Crypt.h index 7a38e1bdb52..c7fb1d5948f 100644 --- a/docs/tutorials/015/Crypt.h +++ b/docs/tutorials/015/Crypt.h @@ -18,7 +18,7 @@ public: // Again we have the option of multiple threads and again I // regret tempting folks to use it. Crypt( int _thr_count = 0 ); - + ~Crypt(void); protected: diff --git a/docs/tutorials/015/Handler.h b/docs/tutorials/015/Handler.h index 7e3123f7cf2..73aa2573b0c 100644 --- a/docs/tutorials/015/Handler.h +++ b/docs/tutorials/015/Handler.h @@ -5,6 +5,11 @@ #define HANDLER_H #include "ace/Svc_Handler.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/SOCK_Stream.h" #include "Protocol_Stream.h" @@ -33,7 +38,7 @@ public: // differences between destroy() and close() so don't try to // use either for all cases. int close (u_long); - + protected: // Respond to peer() activity. diff --git a/docs/tutorials/015/Protocol_Stream.h b/docs/tutorials/015/Protocol_Stream.h index 384e7240e4f..686d39126e0 100644 --- a/docs/tutorials/015/Protocol_Stream.h +++ b/docs/tutorials/015/Protocol_Stream.h @@ -5,6 +5,11 @@ #define PROTOCOL_STREAM_H #include "ace/SOCK_Stream.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/Stream.h" // Shorthand for the stream. @@ -46,18 +51,18 @@ public: _timeout = 0 ); // Tell the Recv task to read some data and send it upstream. - // The data will pass through the protocol tasks and be queued + // The data will pass through the protocol tasks and be queued // into the stream head reader task's message queue. If // you've installed a _reader in open() then that task's // recv() method will see the message and may consume it // instead of passing it to the stream head for queueing. int get(void); - + ACE_SOCK_Stream & peer(void) { return this->peer_; } - + private: // Our peer connection ACE_SOCK_Stream peer_; diff --git a/docs/tutorials/015/Protocol_Task.h b/docs/tutorials/015/Protocol_Task.h index eeec1d71588..194809327ec 100644 --- a/docs/tutorials/015/Protocol_Task.h +++ b/docs/tutorials/015/Protocol_Task.h @@ -6,6 +6,10 @@ #include "ace/Task.h" +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + /* A typical ACE_Task<> derivative that adds a few things appropriate to protocol stacks. */ @@ -20,13 +24,13 @@ public: // zero and let things proceed serially. You might have a // need, however, for some of your tasks to have their own thread. Protocol_Task( int _thr_count ); - + ~Protocol_Task(void); // open() is invoked when the task is inserted into the stream. virtual int open(void *arg); - // close() is invoked when the stream is closed (flags will be + // close() is invoked when the stream is closed (flags will be // set to '1') and when the svc() method exits (flags will be // '0'). virtual int close(u_long flags); @@ -36,13 +40,13 @@ public: virtual int put(ACE_Message_Block *message, ACE_Time_Value *timeout); - // If you choose to activate the task then this method will be + // If you choose to activate the task then this method will be // doing all of the work. virtual int svc(void); protected: - // Called by put() or svc() as necessary to process a block of + // Called by put() or svc() as necessary to process a block of // data. int process(ACE_Message_Block * message, ACE_Time_Value *timeout); @@ -57,7 +61,7 @@ protected: // the peer. virtual int send(ACE_Message_Block *message, ACE_Time_Value *timeout); - + // Tasks on the reader (upstream) side will be receiving data // that came from the peer. virtual int recv(ACE_Message_Block * message, diff --git a/docs/tutorials/015/Recv.h b/docs/tutorials/015/Recv.h index 4514f816aa9..a7058435bf5 100644 --- a/docs/tutorials/015/Recv.h +++ b/docs/tutorials/015/Recv.h @@ -19,7 +19,7 @@ public: // Give it someone to talk to... Recv( ACE_SOCK_Stream & _peer ); - + ~Recv(void); // Trigger a read from the socket @@ -32,7 +32,7 @@ public: { return this->error_; } - + protected: ACE_SOCK_Stream & peer(void) diff --git a/docs/tutorials/015/Server.h b/docs/tutorials/015/Server.h index 0e6b9f9c9cf..6b1eecf05e5 100644 --- a/docs/tutorials/015/Server.h +++ b/docs/tutorials/015/Server.h @@ -5,6 +5,11 @@ #define SERVER_H #include "ace/Acceptor.h" + +#if !defined (ACE_LACKS_PRAGMA_ONCE) +# pragma once +#endif /* ACE_LACKS_PRAGMA_ONCE */ + #include "ace/SOCK_Acceptor.h" #include "Handler.h" @@ -36,7 +41,7 @@ public: int run(void); private: - // This will accept client connection requests and instantiate + // This will accept client connection requests and instantiate // a Handler object for each new connection. Acceptor acceptor_; diff --git a/docs/tutorials/015/Xmit.h b/docs/tutorials/015/Xmit.h index 7d8df91e0ef..097f3afdaba 100644 --- a/docs/tutorials/015/Xmit.h +++ b/docs/tutorials/015/Xmit.h @@ -21,14 +21,14 @@ public: // We must be given a valid peer when constructed. Without that // we don't know who to send data to. Xmit( ACE_SOCK_Stream & _peer ); - + ~Xmit(void); - // As you know, close() will be called in a couple of ways by the + // As you know, close() will be called in a couple of ways by the // ACE framework. We use that opportunity to terminate the // connection to the peer. int close(u_long flags); - + protected: ACE_SOCK_Stream & peer(void) |