From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fed2e7871ca258cd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-15 08:51:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn4feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!rwcrnsc51.POSTED!not-for-mail From: "Steve Doiel" Newsgroups: comp.lang.ada References: Subject: Re: Server - tasking and long lived connections X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Sat, 15 Dec 2001 16:51:36 GMT NNTP-Posting-Host: 192.168.198.212 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc51 1008435096 192.168.198.212 (Sat, 15 Dec 2001 16:51:36 GMT) NNTP-Posting-Date: Sat, 15 Dec 2001 16:51:36 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17952 Date: 2001-12-15T16:51:36+00:00 List-Id: I certainly wouldn't rule out a tasking arrangement using one task per N file descriptors, where the number of file descriptors handled for each task is target specific. I know that the "select" function on some targets have a limit on the number of file descriptors, while other targets have a limit on the number of tasks that may be used. Our applications run on Winows NT 4.0. We use more than one task for each connection (input, output and connection maintainence). We typically have a few dozen connections. This implementation proves to be very simple and easy to maintain. But you're talking about a lot more connections. SteveD "Eric Merritt" wrote in message news:mailman.1008382022.25904.comp.lang.ada@ada.eu.org... > Hello All, > > I am in the process of designing a server that will > need to accept long lived (up to several hours) client > connections. The processes themselves will be fairly > I/O bound (database accesses), and at most the number > of processors will be in the range of 2 - 4. The > obvious choice (in my mind) for this is to use a > single task per connection. In this senario, context > switching will not be a major issues due to the length > of the connections. There will be little or no > performance gains by using tasking, but it handles the > long connection times well. > > I do, however, have a few reservations about > scalablity due to OS limitations on the number of > threads per machine and the number of open file > descriptors. Although at first the number of > connections will not be high, it is possible that it > could rapidly need to scale up to a fairly high > number, several hundred or more. This may mean that I > will just have to distribute the app across several > boxs and do some type of mirroring on the databases, > but I want to put that off as long as possible. > > I have quit a bit of experience in code this type of > application but usually with short lived connections > or a low number of total connections. > > Anyway, I am just looking for some one to either point > me in a different direction or confirm my current > approach (one thread per connection). > > Thank you for your input. > > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com