diff options
Diffstat (limited to 'docs/tutorials/006/page04.html')
| -rw-r--r-- | docs/tutorials/006/page04.html | 91 |
1 files changed, 44 insertions, 47 deletions
diff --git a/docs/tutorials/006/page04.html b/docs/tutorials/006/page04.html index a203c7608a8..3e2002b1d52 100644 --- a/docs/tutorials/006/page04.html +++ b/docs/tutorials/006/page04.html @@ -15,7 +15,6 @@ <P> <HR WIDTH="100%"> - <P><A HREF="client_handler.h">client_handler.h</A> shows a few more changes than the previous sources. The important change is the addition of a svc() method where our connection thread will @@ -23,12 +22,14 @@ exist. <P> <HR WIDTH="100%"> +<PRE> + +<font color=red>// $Id$</font> -<pre><FONT FACE="Arial,Helvetica"> -#ifndef CLIENT_HANDLER_H -#define CLIENT_HANDLER_H +<font color=blue>#ifndef</font> <font color=purple>CLIENT_HANDLER_H</font> +<font color=blue>#define</font> <font color=purple>CLIENT_HANDLER_H</font> -/* +<font color=red>/* 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 @@ -38,64 +39,64 @@ exist. 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. - */ + */</font> -#include "ace/Svc_Handler.h" +<font color=blue>#include</font> "<font color=green>ace/Svc_Handler.h</font>" -#if !defined (ACE_LACKS_PRAGMA_ONCE) +<font color=blue>#if !defined</font> (<font color=purple>ACE_LACKS_PRAGMA_ONCE</font>) # pragma once -#endif /* ACE_LACKS_PRAGMA_ONCE */ +<font color=blue>#endif</font> <font color=red>/* ACE_LACKS_PRAGMA_ONCE */</font> -#include "ace/SOCK_Stream.h" +<font color=blue>#include</font> "<font color=green>ace/SOCK_Stream.h</font>" -/* - Another feature of ACE_Svc_Handler is it's ability to present the ACE_Task<> +<font color=red>/* + 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() method will execute. We still don't take advantage of the thiings ACE_NULL_SYNCH exists for but stick around for Tutorial 7 and pay special attention to the Thread_Pool object there for an explanation. - */ -class Client_Handler : public ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH > + */</font> +class Client_Handler : public ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH > { public: - typedef ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH > inherited; + typedef ACE_Svc_Handler < ACE_SOCK_STREAM, ACE_NULL_SYNCH > inherited; - // Constructor... + <font color=red>// Constructor...</font> Client_Handler (void); - /* + <font color=red>/* The destroy() method is our preferred method of destruction. We could have overloaded the delete operator but that is neither easy nor 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. - */ + */</font> void destroy (void); - /* + <font color=red>/* 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 create this overrride. ACE_Acceptor<> will invoke this method after + 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 - 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 + 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. - */ + */</font> int open (void *_acceptor); - /* - When an ACE_Task<> object falls out of the svc() method, the framework + <font color=red>/* + 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. - */ + */</font> int close(u_long flags = 0); - /* + <font color=red>/* When there is activity on a registered handler, the handle_input() method of the handler will be invoked. If that method returns an error code (eg -- -1) then the reactor will invoke handle_close() to allow the object to @@ -107,61 +108,57 @@ public: As a side-effect, the reactor will also invoke remove_handler() for the object on the mask that caused the -1 return. This means that we don't have to do that ourselves! - */ - int handle_close (ACE_HANDLE _handle, ACE_Reactor_Mask _mask); + */</font> + virtual int handle_close (ACE_HANDLE _handle = ACE_INVALID_HANDLE, + ACE_Reactor_Mask _mask = <font color=#008888>ACE_Event_Handler::ALL_EVENTS_MASK</font> ); protected: - /* + <font color=red>/* If the Client_Acceptor which created us has chosen a thread-per-connection strategy then our open() method will activate us into a dedicate thread. The svc() method will then execute in that thread performing some of the functions we used to leave up to the reactor. - */ + */</font> int svc(void); - /* + <font color=red>/* When we register with the reactor, we're going to tell it that we want to be notified of READ events. When the reactor sees that there is read activity for us, our handle_input() will be invoked. The _handleg provided is the handle (file descriptor in Unix) of the actual connection - causing the activity. Since we're derived from ACE_Svc_Handler<> and it + causing the activity. Since we're derived from ACE_Svc_Handler<> and it 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. - */ + */</font> int handle_input (ACE_HANDLE _handle); - /* + <font color=red>/* This has nothing at all to do with ACE. I've added this here as a worker function which I will call from handle_input(). As promised in Tutorial 5 I will use this now to make it easier to switch between our two possible concurrency strategies. - */ + */</font> int process (char *_rdbuf, int _rdbuf_len); - /* + <font color=red>/* 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. - */ + */</font> ~Client_Handler (void); }; -#endif // CLIENT_HANDLER_H -</pre> +<font color=blue>#endif</font> <font color=red>// CLIENT_HANDLER_H</font> +</PRE> <HR WIDTH="100%"> <P>So... we've added a svc() method and alluded to changes in open(). Let's move on to the object definition and see what all the fuss is about. <P> -<HR WIDTH="100%"> -<CENTER>[<A HREF="..">Tutorial -Index</A>] [<A HREF="page05.html">Continue -This Tutorial</A>]</CENTER> - -</BODY> -</HTML> +<P><HR WIDTH="100%"> +<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page05.html">Continue This Tutorial</A>]</CENTER> |