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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed01.chello.at!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Advice on abort Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Tue, 8 Nov 2005 17:14:06 +0100 Message-ID: <1ozi307fng5fi$.1ms3kyzc7defi$.dlg@40tude.net> NNTP-Posting-Date: 08 Nov 2005 17:14:06 MET NNTP-Posting-Host: d6840442.newsread4.arcor-online.net X-Trace: DXC=Zo8UYiPDHoUkVRFeeUa4iQ:ejgIfPPldTjW\KbG]kaMX1BZS;MmC65V>b?iM 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. >> 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de