[GAP] Deferred task aborting and get_immediate

[Pierre Habraken]

Arnaud Charlet wrote:
>>When the task below is blocked in get_immediate, it can not be aborted 
>>using the statement "abort TacheEcouteClavier" : aborting the task is 
>>deferred until get_immediate returns.
>>
>>Is this a feature of the language or a particularity of Gnat 
>>implementation ?
> [...]
> Note that it's in any case a bad idea to try to abort asynchronousely this
> kind of operation (in this case a system I/O call) since there is no way
> in general to ensure proper clean up or system calls.
> 
> It's in general far preferable to use an explicit "manual" abort mechanism
> via e.g. a rendezvous.

I agree, however I can't figure how to terminate without "killing" it a 
task which is blocked in an I/O call.
I would expect that the runtime uses posix signal in order to interrupt 
such blocking system calls. I understand that it does not by default.
A workaround could be to periodically poll the keyboard input, using non 
blocking get_immediate. But I don't like it because it generates 
unnecessary context switches and processor time wasting.
BTW, a task using blocking reads on a network socket (XNextEvent Xlib 
primitive, see below) gently terminates when asynchronously aborted. I 
suppose that this is because the Xlib and the Gnat runtime do manage I/O 
calls in a different way each one...

Pierre

===================================
task body TacheEcouteConnexionX is
    evenement_recu : aliased XEvent;
begin
    accept demarrer;
    loop
       XNextEvent(display, evenement_recu'access);
       ...
    end loop;
end TacheEcouteConnexionX;
===================================
-- 
Pierre HABRAKEN - mailto:Pierre.Habraken at imag.fr
Tél: 04 76 82 72 46 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex