[Rd] interrupting native code

[Kjell Konis]

You mean something like this (I return 1 instead of calling onintr())?  
Will HAVE_AQUA and Win32 be appropriately defined when building my  
package (I can't see how to check with R CMD config)?

int My_CheckUserInterrupt(void)
{
     R_CheckStack();

#if  ( defined(HAVE_AQUA) )

   /* R_ProcessEvents() from unix/aqua.c*/

   if (ptr_R_ProcessEvents)
     ptr_R_ProcessEvents();
   if (R_interrupts_pending)
     return(1);

#elseif ( defined(Win32) )

   /* R_ProcessEvents() from gnuwin32/system.c */

     while (peekevent()) doevent();
     if (UserBreak) {
	UserBreak = FALSE;
	return(1);
     }
     R_CallBackHook();
     if(R_tcldo) R_tcldo();

#else

     R_PolledEvents();
     if (R_interrupts_pending)
	return(1);

#endif

   return(0);
}




On 16 mai 08, at 12:43, Prof Brian Ripley wrote:

> On Fri, 16 May 2008, Kjell Konis wrote:
>
>> The problem is that my package uses an external pointer to keep  
>> track of a structure created by the lp_solve library. If I use  
>> R_CheckUserInterrupt in the lp_solve abort function it leaves the  
>> structure in a messed-up state after an interrupt occurs. I am not  
>> even able to free the memory allocated in the structure. I need to  
>> be able to tell the lp_solve functions to interrupt themselves if I  
>> am going to support interrupts at all.
>>
>> I took a longer look at errors.c and it seems my solution should  
>> work as long as neither HAVE_AQUA nor Win32 are defined. Under the  
>> circumstances, I think that's the best I can do.
>>
>> Any suggestions for a UI independent way to check for interrupts  
>> would be appreciated.
>
> Why not use the same code as R_CheckUserInterrupt but instead of  
> calling onintr, call your own interrupt routine?
>
>>
>> Thanks,
>> Kjell
>>
>> On 15 mai 08, at 16:41, Prof Brian Ripley wrote:
>>
>>> How is R_interrupts_pending going to be set?
>>> It is set in the interrupt handler for SIGINT, but that is not the  
>>> only way to indicate an interrupt, and it is not necessarily  
>>> available to users of GUIs and embedded R.
>>> Without servicing the GUIs all interaction will be dead, including  
>>> sending an interrrupt from menus/buttons/keyboard.  See the  
>>> comment in the code for R_CheckUserInterrupt.
>>> On Thu, 15 May 2008, Kjell Konis wrote:
>>>> Hello,
>>>> I have some native code that I would like to allow users to  
>>>> interrupt. However, I would like to do it more gracefully than  
>>>> with R_CheckUserInterrupt(). The solution I came up with is to  
>>>> call the following abort function periodically - if it returns 1  
>>>> then I clean up and return.
>>>> int __WINAPI RlpSolveAbortFunction(lprec *lp, void *userhandle)
>>>> {
>>>> if(R_interrupts_pending)
>>>> return(1);
>>>> return(0);
>>>> }
>>>> This seems to work fine on Mac (sans Aqua) and Linux. Is this  
>>>> going to be portable?  Also, is there anything else I need to  
>>>> do?  For instance set R_interrupts_pending to 0 after I respond  
>>>> to it?
>>>> Thanks.
>>>> Kjell
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> -- 
>>> Brian D. Ripley,                  ripley at stats.ox.ac.uk
>>> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>>> University of Oxford,             Tel:  +44 1865 272861 (self)
>>> 1 South Parks Road,                     +44 1865 272866 (PA)
>>> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595