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,be3d89c2ad66a506 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!not-for-mail Date: Tue, 08 Nov 2005 17:59:41 +0100 From: Poul-Erik Andreasen User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Advice on abort References: <1131117934.372137.244900@g44g2000cwa.googlegroups.com> <436f6ad8$0$196$edfadb0f@dread11.news.tele.dk> <1131383393.903975.180350@g47g2000cwa.googlegroups.com> <1rb5pcog6iau7$.180ltiuk2q6cv.dlg@40tude.net> <4370bc36$0$180$edfadb0f@dread11.news.tele.dk> <1ozi307fng5fi$.1ms3kyzc7defi$.dlg@40tude.net> In-Reply-To: <1ozi307fng5fi$.1ms3kyzc7defi$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4370d97d$0$141$edfadb0f@dread11.news.tele.dk> Organization: TDC Totalloesninger NNTP-Posting-Host: 80.166.145.174 X-Trace: 1131469181 dread11.news.tele.dk 141 80.166.145.174:48489 X-Complaints-To: abuse@post.tele.dk Xref: g2news1.google.com comp.lang.ada:6290 Date: 2005-11-08T17:59:41+01:00 List-Id: Dmitry A. Kazakov wrote: > On Tue, 08 Nov 2005 15:54:45 +0100, Poul-Erik Andreasen wrote: > > >>Dmitry A. Kazakov wrote: >> >>>On 7 Nov 2005 09:09:53 -0800, REH wrote: >>> >>> >>>>Poul-Erik Andreasen wrote: >>>> >>>> >>>>>REH wrote: >>>>> >>>>> >>>>>>What are the best options when a task needs to be terminated, but >>>>>>signaling the task may not be possible? We have tasks that sometimes >>>>>>need to be terminated, but may potentially be blocked on a resource, >>>>>>such as a socket. Currently we use OS-specific calls to terminate the >>>>>>task, but I've never liked that. I've been thinking of using the abort >>>>>>statement, but I don't think that's very graceful either. I also would >>>>>>rather not complicate the code (or force polling behavior) by making >>>>>>the sockets non-blocking. Any advice? >>>>>> >>>>> >>>>>One poosibillty is too use asyncronius transfer of control. Somthing >>>>>like this. >>>>> >>>>>select >>>>> call.foo_entry -- this i is a guarded entry in a protected >>>>>object or -- another task >>>>> -- her can you have anything yuo may need to clean up after the abort >>>>>then abort >>>>> listen_to_socket this is the function wich may be blocked >>>>>end select >>>>> >>>>>Thee foo_entry basicly dosen't need to do anything. an you have onother >>>>>procedure or entry to open it. >>>> >>>>I was once advised never to use ATC because it is very slow. Is this >>>>true? It was in reference to GNAT. >>> >>>That is not the main concern. The problem is the state in which aborting >>>would leave the socket and the corresponding port. > > >>I am not that good at sockets, So i vould like to know wich problematic >>(uncleanable) states wee are taking about. > > > It all depends on the particular implementation of the socket library and > how Ada tasks are mapped to system threads and processes. All sorts of > resource leaks are thinkable. For example, you might be unable to listen > that TCP/IP port until process restart or it won't abort etc. The time of the abortion are at the end of the first part of the ACT so a cant se how the following could make any problems. select call.foo_entry -- this i is a guarded entry in a protected object or Abort_select close_socket --this is the time of the abortion then abort listen_to_socket this is the function wich may be blocked end select -- check here if socket realy are closed; >>>Note also that what you want to do is not an Ada issue at all. Actually you >>>don't want to abort any Ada task. What you want is to cancel an OS >>>operation blocking some Ada task. This can be done *only* by means of the >>>OS being under consideration. There are little choices: >>> >>>1. Asynchronous I/O without blocking >>> >>>2. Synchronous I/O with some cancel operation invoked from outside (like >>>closing socket, or Abort_Selection proposed by Marc Criley) >> >>This will however require that the sockets or select are made public in >>some way, wich a dont like. > > > Not necessarily. It seems natural to decouple A) the higher level protocol > [encapsulates a task] from B) the communication object [likely passive, > encapsulates socket, COM port etc]. > > type B is abstract new Root_Stream_Type with ... -- Abortable streams > procedure Abort is abstract; > > type Socket_Stream is new B with private ...; > type COM_Stream is new B with private ...; > > type A (Stream : access B'Class) is ...; > procedure Abort (X : in out A); > private > type A ... record > Reader : Some_Task_Ptr; > end record; > > procedure Abort (X : in out A) is > begin > Abort (X.Stream); -- Aborts I/O > Free (Reader); -- Terminates the task > end Abort; > > With Ada 2005 interfaces one could even avoid mix-ins. Well, instead of exporting them you import them into the task from the beginning. I am not saying that it is impossible to make an incapsulation. PEA