Re: Advice on abort

[Poul-Erik Andreasen <poulerik@pea.dk>]

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