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 Received: by 10.68.135.231 with SMTP id pv7mr8628951pbb.8.1327452213049; Tue, 24 Jan 2012 16:43:33 -0800 (PST) Path: lh20ni220504pbb.0!nntp.google.com!news2.google.com!postnews.google.com!rk3g2000pbb.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: "C - like: THIS" pointer to a task type inside a task function Date: Tue, 24 Jan 2012 16:42:00 -0800 (PST) Organization: http://groups.google.com Message-ID: <3deb0849-ec07-4cc5-b722-a253b614feee@rk3g2000pbb.googlegroups.com> References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1327452212 12638 127.0.0.1 (25 Jan 2012 00:43:32 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 25 Jan 2012 00:43:32 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: rk3g2000pbb.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-01-24T16:42:00-08:00 List-Id: On Jan 23, 11:32=A0am, Ada BRL wrote: > Dear all, > > I'm experiencing an issue about local and not local pointers... > > 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). > For this reason the server needs to know on which client call the > entry: > one time could be the 3th, another the 1st and so on... I think you should look into protected types, which may be the best way to solve your problem (or at least some other problems that may be like yours). I'm not sure what exactly you're trying to do, but it sounds something like this: You have a server and a number of clients. Each client may, at some point, initiate a certain kind of request to the server. The client may want to do other things (OK, that might be Tom's idea and not yours) and then, when it's done, wait for the request to be completed and retrieve the result data from the server. I think the problem is that using "accept" to wait for the server to complete the request doesn't work very well, especially when your clients are of several different task types. There's no way in Ada to get the server to call a Receive entry without knowing the type of the task declaring the entry; even if the entries of different task types all have the same name Receive and the same parameter profile, it just won't work. J-P mentioned using interfaces but I think this could get messy. A better idea (in my opinion) is to set things up so that the client will *call* an entry, rather than accept an entry, when it's ready to wait for the request to be completed. It can't be an entry in the server, though, since there's no construct in Ada to "accept" an entry just from one specific task. In Ada 83, I would have had the server create a new, small "helper" task for this purpose; the server would create a new task when the request is initiated, and later it would tell that task when the request can be completed, and the client would wait on that task. Now, protected types can be used for a similar purpose. Something like: protected type Request_Control is entry Retrieve_Data (Data : String); -- other entries that the server would use end Request_Control; type Request_Control_Acc is access all Request_Control; Then, the client would do something like: Req : Request_Control_Acc; loop Server.Send_Data (Data, Req); -- where Req is an OUT parameter -- to the entry -- do some other stuff -- then when you're ready to retrieve the result: Req.Retrieve_Data (Data); -- etc. end loop; The server, when it gets Send_Data, would allocate a new Request_Control and give the access back to the client. The server would also save this access in its own tables so that it can communicate with it when it's ready to signal that the request is complete. Later, the server would call some other operation of Request_Control when the request is complete, and this would open up the Retrieve_Data entry so that the client can now unblock (if it is waiting on Retrieve_Entry) and retrieve the data. This would also work if your client has two tasks and you want one task to initiate the request and the other to retrieve the data (I'm not sure if this is what you meant in one of your later posts). The first task would just have to get the Req value to the second task somehow. I'll let you read about protected types and figure out how you'd set them up to make everything work. Again, I don't know if this is exactly the kind of problem you're trying to solve, but something like this would help with a lot of problems in the same class, so hopefully it will be of some use. -- Adam