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@gmx.net To: tomhoward@users.sourceforge.net, Boost-Users@yahoogroups.com > 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@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/