Re: Advice on abort

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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