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-Thread: 103376,57893ac51069959a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.213.68 with SMTP id nq4mr414315pbc.2.1327551475353; Wed, 25 Jan 2012 20:17:55 -0800 (PST) MIME-Version: 1.0 Path: lh20ni224780pbb.0!nntp.google.com!news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: "C - like: THIS" pointer to a task type inside a task function Date: Wed, 25 Jan 2012 22:17:51 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> <2c51ce87-87ef-438c-bec5-e3b8114f0471@cf6g2000vbb.googlegroups.com> <1rp216zwnjx3j$.rjwu8m3hxgp1.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1327551474 2335 69.95.181.76 (26 Jan 2012 04:17:54 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 26 Jan 2012 04:17:54 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-01-25T22:17:51-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1rp216zwnjx3j$.rjwu8m3hxgp1.dlg@40tude.net... ... > Note one important advantage of having a queue of requests rather than > communicating directly to the server. The queue decouples the readers from > the server. So you could have two or three servers processing the requests > from the queue. On a multi-core architecture that could give you better > throughout. The number of servers can be adjusted later, you need not to > decide it upfront as you would with direct rendezvous. Right. My spam filter is structured this way. There is a pool of tasks for processing connections, and a manager task that initially receives connections and assigns them to tasks. If there aren't any tasks available, the filter is getting overloaded and the extra connections are just dropped (SMTP will retry them in a while if real, and if junk, who cares?). The connections are processed, and presuming that the connection is not blocked, the incoming mail message is read, a token created for it, and that is queued on the filter queue. There is then a pool of filter tasks, which grab message tokens from the queue, filter the message, and determine what to do with it - delete, quarantine, or deliver. Delete is obvious, quarantine just involves moving the message files to a special place, and in the deliver case the token is put on a delivery queue. And delivery works the same way: there is a pool of delivery tasks, which take messages off the delivery queue whose delivery time is current, and tries to deliver them. If successful, the message is deleted from the server; otherwise it is put back on the delivery queue with a time in the future (in order to support retries). There are a lot more details (like returning non-delivery messages if a message has been retried too long), but that it is general outline -- and it works great. (All of the mail going to the Ada-Comment mailing list, along with many others, goes thru our spam filter - a 100% Ada program.) Randy.