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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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 Received: by 10.68.213.68 with SMTP id nq4mr10379935pbc.2.1327495437362; Wed, 25 Jan 2012 04:43:57 -0800 (PST) Path: lh20ni222344pbb.0!nntp.google.com!news1.google.com!postnews.google.com!cf6g2000vbb.googlegroups.com!not-for-mail From: Ada BRL Newsgroups: comp.lang.ada Subject: Re: "C - like: THIS" pointer to a task type inside a task function Date: Wed, 25 Jan 2012 04:43:57 -0800 (PST) Organization: http://groups.google.com Message-ID: <2c51ce87-87ef-438c-bec5-e3b8114f0471@cf6g2000vbb.googlegroups.com> References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> NNTP-Posting-Host: 164.11.203.58 Mime-Version: 1.0 X-Trace: posting.google.com 1327495437 869 127.0.0.1 (25 Jan 2012 12:43:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 25 Jan 2012 12:43:57 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: cf6g2000vbb.googlegroups.com; posting-host=164.11.203.58; posting-account=yig7mwoAAAAAcduNbH7Dpal1sjCSAijA User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUARELSCNK X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7,gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-01-25T04:43:57-08:00 List-Id: On 24 Gen, 18:43, "Dmitry A. Kazakov" wrote: > On Tue, 24 Jan 2012 09:12:03 -0800 (PST), Ada BRL wrote: > > On 23 Gen, 19:59, "Dmitry A. Kazakov" > > wrote: > >> On Mon, 23 Jan 2012 11:32:39 -0800 (PST), Ada BRL wrote: > >>> I've N clients and one server that communicate each other. > >>> The N clients retrieve data dynamically, send it to the server throgh > >>> enrty call (obviously the server can accept just one call per time) > >>> and wait for the reply from the server (through accept statement). > > >> A server cannot wait for itself either "through accept statement" or a= ny > >> other way. > > >> =A0 =A0T4.Send_Data (Data); > >> =A0 =A0accept Retrieve_Data (Data); > > >> is a patented way to run into a deadlock. > > > yes...you are right ... sorry ... =3D( BUT I MADE A MISTAKE!!! > > > There are two tasks for every communication channel: > > - one performing input, so retrieving data from the net and sending it > > to the server (call it T1_IN, T2_IN, ...) > > - one performing output, so retrieving data from the server and > > sending it on the net (call it T1_OUT, T2_OUT, ...) > > OK. When you are working with sockets you normally do not need a dedicate= d > output task. The network stack is already buffered and most likely > asynchronous to the sender once you have initiated send. Thus you could > consider sending data straight out of the server. So, please tell me if I'm right, the server has to implement inside itself the N output socket connections and I just need to have N tasks implementing a socket connection each useful just for reading data from the net and forwarding it to the server? Note also that unless you > have a relatively small number of sockets to handle (a dozen or so), a ta= sk > per socket doing blocking read would not scale. Are you referring to the tasks reading from the net? Tasks are used to read > sockets simply because it is easier to program this way. If you have 2-3 > sockets, why bother with asynchronous socket I/O? So I don't have to use tasks neither for reading? Sorry but I haven't got the concept... But you won't likely get > a better performance in terms of data throughout and latencies with > separate reader/writer tasks. Having one server engaging rendezvous with > writers that would make this design even less reasonable. That is because > you have the jobs *serialized* in the server. Writers will be either idle > most of the time waiting for the server or else block server, which would > want to make a rendezvous with a *concrete* writer each time. You would > gain nothing from parallelism here, because serialization of processing i= s > enforced by server, it only appears parallel. Unless there is some > considerable post-processing in the writers, it would rather eat > performance on meaningless task switching. The writers just receive data from the server and send it over the net... now I recognize it's not a well designed software... :-(... Just to see if I have understood everything: - NO "writers tasks", - N "readers tasks": every task has just one connection (socket) to the peer from which receives data, - Server is connected (by sockets) to N clients to which sends data after elaboration, - Server has one entry like: entry Receive_Data(Id_Reader_task : in Integer; Data : in String), and inside its infinite loop accept this entry, - the generic "reader task" i calls the entry of the server like: Server.Receive_Data(i, data); Thank you very much! You have "opened my eyes"! > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de