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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8eff44ec1bcf8433 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-17 09:33:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!193.251.151.101!opentransit.net!wanadoo.fr!proxad.net!feeder2-1.proxad.net!news.free.fr!not-for-mail Message-ID: <3BCDB29B.EBD01D8C@free.fr> Date: Wed, 17 Oct 2001 18:32:27 +0200 From: Jean-Marc Bourguet X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Container reqs References: <9qctpn$lil$1@news.huji.ac.il> <3BCC01B1.18C18C98@free.fr> <3BCC6CB7.20BAA30D@boeing.com> <3BCD2EC3.3B3C4498@free.fr> <3BCD91D9.C77668AA@free.fr> <8ghz7.32783$ev2.39537@www.newsranger.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Date: 17 Oct 2001 18:33:23 MEST NNTP-Posting-Host: 158.140.208.29 X-Trace: 1003336403 news1-1 848 158.140.208.29 Xref: archiver1.google.com comp.lang.ada:14826 Date: 2001-10-17T18:33:23+02:00 List-Id: Ted Dennison wrote: > > In article <3BCD91D9.C77668AA@free.fr>, Jean-Marc Bourguet says... > > > >Ted Dennison wrote: > >> > >> But your "level 4" is exactly what is needed for the "gender-bender" > >> server-to-server queue we were referring to. This is a *quite* common need. > >> Its come up in every multitasking Ada app I've ever written of at least > >> moderate complexity. Your assertion is quite wrong too. When used as I > >> described, it is the *only* communication the two server tasks need. In > >> fact, it is the only safe communication method they can have. > > > >There is a possibility I don't understand what you are refering to -- so > >if you think it is the case, please explain it more thorougly. > > The way this has to work is that server task 1 enqueues events/info/whatever and > server task 2 goes and dequeues that stuff whenever it finds some there. There > clearly may be times when server task 1 is enqueing while server task 2 is > dequeueing from the same queue. [...] That's what I had understood. I put this in level 3 (but as I wrote in my previous post, for a queue the difference between level 3 and level 4 is tiny). But I don't think it is a good argument in favor of working hard and complexifying the library in order to be able to modify a tree from several tasks using shared iterators. -- Jean-Marc