|
Boost Users : |
From: dick.bridges_at_[hidden]
Date: 2002-08-29 12:03:53
My $.02. Check out the description of the Leader-Follower thread pattern
described in Schmidt, et al, Pattern-Oriented Software Architecture, Volume
2, Patterns for Concurrent and Networked Objects.
Sure is easy to implement with Boost libraries. Thank you everyone!
Luis De la Parra
<lparrab_at_[hidden] To: tomhoward_at_[hidden], Boost-Users_at_[hidden]
> cc:
Subject: Re: [Boost-Users] threads and signals question
08/29/2002 09:37
AM
Please respond
to Boost-Users
> IMHO I wouldn't use select. Each time a new connections is initiated,
you
> can simply start a new thread to receive data from that socket. I don't
> know what performance impact this would have, but the code will certainly
> be simpler and easier to maintain.
as I said, I'm new to threads.. and I know they are much more
"leightweighted"
than a normal process, but imagine a server, like an application server,
which can have *a lot* of clients connected at the same time, but in which
the clients are not really all requesting thigs all the time, they are
"just
connected"
I think having a thread waiting on each open connection is not the right
approach here, so I thought of going a kind of "production line" approach
in
which a few threads (5-10) are reading the data from a bunch of open
connections (50-100), the only thing they do is read the data, parse it and
form a "Request" which they put in a queue for further processing and then
go
on to service the other connections.
Then another group of threads is taking this requests and doing something,
and
putting Response objects in yet another queue, which another group of
threads
"Sender" is taking and sending thorugh the socket.
I think you get the idea: a frew threads just doing one thing and then
passing
the processing to another gorup of threads.
I know having a thread dedicated to each connection would be much easier,
but
since this project is mostly for fun (and to learn!) I'd like to take a
"better" approach (note that I am not saying the approach I just described
is the best one, but right now it sounds more efficient and scalable to me
than the one-trhead-per-connection approach)
regards,
luis.l
Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe_at_[hidden]>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net