[GAP] Deferred task aborting and get_immediate

[Ted Baker]

Dear Arno,

I believe GNARL did support abort of threads blocked on input,
when I worked on it.  That is, if you send an abort signal
to a thread blocked on I/O, and you have opened the file with
in most Unix/Linux systems any pending read operation should return with
E_INTR and allow GNARL to check for pending abort (before restarting the
read, if necessary).  Has this changed?

--Ted

On Thu, Sep 07, 2006 at 10:10:18AM +0200, Arnaud Charlet wrote:
> > I agree, however I can't figure how to terminate without "killing" it a 
> > task which is blocked in an I/O call.
> 
> You cannot, you need to use some kind of polling.
> 
> > 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.
> 
> You just need to use proper timeouts to avoid using too much cpu.
> 
> > 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...
> 
> XNextEvent will typically return very frequently, so I suspect the abortion
> is actually not taking place during the XNextEvent call.
> 
> Arno
> _______________________________________________
> GAP mailing list
> GAP at gnat.info
> /no-more-mailman.html
> To unsubscribe from this list, please contact the GAP GNAT Tracker administrator
> within your organization.