1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
<!-- $Id$ -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; Linux 2.0.32 i486) [Netscape]">
<META NAME="Author" CONTENT="James CE Johnson">
<META NAME="Description" CONTENT="A first step towards using ACE productively">
<TITLE>ACE Tutorial 007</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
<CENTER><B><FONT SIZE=+2>ACE Tutorial 007</FONT></B></CENTER>
<CENTER><B><FONT SIZE=+2>Creating a thread-pool server</FONT></B></CENTER>
<HR>
<P><A HREF="client_handler.cpp">client_handler.cpp</A>
shows some of the changes due to the thread-pool. Just a few
though.
<P>
<HR WIDTH="100%">
<PRE>
<font color=red>// $Id$</font>
<font color=red>/* Since this is the third time we've seen most of this, I'm going to
strip out almost all of the comments that you've already seen.
That way, you can concentrate on the new items. */</font>
<font color=blue>#include</font> "<font color=green>client_acceptor.h</font>"
<font color=blue>#include</font> "<font color=green>client_handler.h</font>"
<font color=red>/* We're going to be registering and unregistering a couple of times.
To make sure that we use the same flags every time, I've created
these handy macros. */</font>
<font color=blue>#define</font> <font color=purple>REGISTER_MASK</font> <font color=#008888>ACE_Event_Handler::READ_MASK</font>
<font color=blue>#define</font> <font color=purple>REMOVE_MASK</font> (<font color=#008888>ACE_Event_Handler::READ_MASK</font> | ACE_Event_Handler::DONT_CALL)
<font color=red>/* Our constructor still doesn't really do anything. We simply
initialize the acceptor pointer to "<font color=green>null</font>" and get our current
thread id. The static self() method of ACE_Thread will return you
a thread id native to your platform. */</font>
<font color=#008888>Client_Handler::Client_Handler</font> (void)
: client_acceptor_(0),
creator_ (<font color=#008888>ACE_Thread::self</font> ())
{
}
<font color=#008888>Client_Handler::~Client_Handler</font> (void)
{
this->peer().close();
}
<font color=red>/* Query our acceptor for the concurrency strategy. Notice that we
don't bother to check that our acceptor pointer is valid. That is
proably a bad idea... */</font>
int
<font color=#008888>Client_Handler::concurrency</font>(void)
{
return this->client_acceptor ()->concurrency ();
}
<font color=red>/* And here we ask the acceptor about the thread pool. */</font>
Thread_Pool *
<font color=#008888>Client_Handler::thread_pool</font> (void)
{
return this->client_acceptor ()->thread_pool ();
}
<font color=red>/* Back to our open() method. This is straight out of Tutorial 6.
There's nothing additional here for the thread-pool implementation. */</font>
int
<font color=#008888>Client_Handler::open</font> (void *acceptor)
{
client_acceptor ((Client_Acceptor *) acceptor);
if (concurrency () == <font color=#008888>Client_Acceptor::thread_per_connection_</font>)
return this->activate (THR_DETACHED);
this->reactor (client_acceptor()->reactor ());
ACE_INET_Addr addr;
if (this->peer ().get_remote_addr (addr) == -1)
return -1;
if (this->reactor ()->register_handler (this,
REGISTER_MASK) == -1)
ACE_ERROR_RETURN ((LM_ERROR,
"<font color=green>(%P|%t) can't register with reactor\n</font>"),
-1);
ACE_DEBUG ((LM_DEBUG,
"<font color=green>(%P|%t) connected with %s\n</font>",
addr.get_host_name ()));
return 0;
}
<font color=red>/* The destroy() method will remove us from the reactor (with the
DONT_CALL flag set!) and then free our memory. This allows us to
be closed from outside of the reactor context without any danger. */</font>
void
<font color=#008888>Client_Handler::destroy</font> (void)
{
this->reactor ()->remove_handler (this, REMOVE_MASK);
delete this;
}
<font color=red>/* As mentioned in the header, the typical way to close an object in a
threaded context is to invoke it's close() method. */</font>
int
<font color=#008888>Client_Handler::close</font> (u_long flags)
{
ACE_UNUSED_ARG(flags);
<font color=red>/*
We use the destroy() method to clean up after ourselves.
That will take care of removing us from the reactor and then
freeing our memory.
*/</font>
this->destroy ();
<font color=red>/* Don't forward the close() to the baseclass! handle_close() above
has already taken care of delete'ing. Forwarding close() would
cause that to happen again and things would get really ugly at
that point! */</font>
return 0;
}
<font color=red>/* We will be called when handle_input() returns -1. That's our queue
to delete ourselves to prevent memory leaks. */</font>
int
<font color=#008888>Client_Handler::handle_close</font> (ACE_HANDLE handle,
ACE_Reactor_Mask mask)
{
ACE_UNUSED_ARG (handle);
ACE_UNUSED_ARG (mask);
delete this;
return 0;
}
<font color=red>/* In the open() method, we registered with the reactor and requested
to be notified when there is data to be read. When the reactor
sees that activity it will invoke this handle_input() method on us.
As I mentioned, the _handle parameter isn't useful to us but it
narrows the list of methods the reactor has to worry about and the
list of possible virtual functions we would have to override.
You've read that much before... Now we have to do some extra stuff
in case we're using the thread-pool implementation. If we're
called by our creator thread then we must be in the reactor. In
that case, we arrange to be put into the thread pool. If we're not
in the creator thread then we must be in the thread pool and we can
do some work. */</font>
int
<font color=#008888>Client_Handler::handle_input</font> (ACE_HANDLE handle)
{
ACE_UNUSED_ARG (handle);
<font color=red>/* Check our strategy. If we're using the thread pool and we're in
the creation thread then we know we were called by the reactor. */</font>
if (concurrency () == <font color=#008888>Client_Acceptor::thread_pool_</font>)
{
if (<font color=#008888>ACE_OS::thr_equal</font> (ACE_Thread::self(),
creator_))
{
<font color=red>/* Remove ourselves from the reactor and ask to be put into
the thread pool's queue of work. (You should be able to
use suspend_handler() but I've had problems with that.)
By removing ourselves from the reactor, we're guaranteed
that we won't be called back until the thread pool picks
us up out of the queue. If we didn't remove ourselves,
then the reactor would continue to invoke handle_input()
and we don't want that to happen. */</font>
this->reactor ()->remove_handler (this, REMOVE_MASK);
return this->thread_pool ()->enqueue (this);
}
}
<font color=red>/* Any strategy other than thread-per-connection will eventually get
here. If we're in the single-threaded implementation or the
thread-pool, we still have to pass this way. */</font>
char buf[BUFSIZ];
<font color=red>/* Invoke the process() method to do the work but save it's return
value instead of returning it immediately. */</font>
int rval = this->process (buf, sizeof (buf));
<font color=red>/* Now, we look again to see if we're in the thread-pool
implementation. If so then we need to re-register ourselves with
the reactor so that we can get more work when it is available.
(If suspend_handler() worked then we would use resume_handler()
here.) */</font>
if (concurrency () == <font color=#008888>Client_Acceptor::thread_pool_</font>)
{
if (rval != -1)
<font color=red>/* If we don't remember to re-register ourselves, then we
won't be able to respond to any future client requests. */</font>
this->reactor ()->register_handler (this,
REGISTER_MASK);
}
<font color=red>/* Return the result of process() */</font>
return rval;
}
<font color=red>/* Remember that when we leave our svc() method, the framework will
take care of calling our close() method so that we can cleanup
after ourselves. */</font>
int
<font color=#008888>Client_Handler::svc</font> (void)
{
char buf[BUFSIZ];
while (1)
if (this->process (buf, sizeof (buf)) == -1)
return -1;
return 0;
}
<font color=red>/* Once again, we see that the application-level logic has not been at
all affected by our choice of threading models. Of course, I'm not
sharing data between threads or anything. We'll leave locking
issues for a later tutorial. */</font>
int
<font color=#008888>Client_Handler::process</font> (char *rdbuf,
int rdbuf_len)
{
ssize_t bytes_read;
switch ( (bytes_read = this->peer ().recv (rdbuf, rdbuf_len)) )
{
case -1:
ACE_ERROR_RETURN ((LM_ERROR,
"<font color=green>(%P|%t) %p bad read\n</font>",
"<font color=green>client</font>"),
-1);
case 0:
ACE_ERROR_RETURN ((LM_ERROR,
"<font color=green>(%P|%t) closing daemon (fd = %d)\n</font>",
this->get_handle ()),
-1);
default:
rdbuf[bytes_read] = 0;
ACE_DEBUG ((LM_DEBUG,
"<font color=green>(%P|%t) from client: %s</font>",
rdbuf));
}
return 0;
}
</PRE>
<HR WIDTH="100%">
<P>Ok, now we've gone and changed handle_input() so that it knows when
to do work and when to enqueue itself. Beyond that, we're still about
the same.
<P><HR WIDTH="100%">
<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page07.html">Continue This Tutorial</A>]</CENTER>
|
