Re: Re: [Beanshell-users] Aborting Interpretting

--- Patrick Niemeyer <[email protected]> wrote:

> 
> Thread interrupt() requires some cooperation from the application that  
> is receiving the interrupt.  Interrupts only generate an exception when  
> the code is in a blocking I/O or sleep operation...  and the rest of  
> the time time the application has to explicitly check for the interrupt  
> condition flag.  It's also possible to simply ignore the interrupt and  
> go about your business.
> 
> BeanShell doesn't currently pay any special attention to the interrupt  
> flag so this won't help now.  But it is likely the best way for us to  
> implement the job control in the enhancement.  We can do this simply by  
> adding checkpoints in the main loop and control structures of  
> BeanShell.  While we can never guarantee that user code that BeanShell  
> invokes will do the same, but at least then our scripts will do the  
> right thing when they have control.  (See various previous threads on  
> this topic).
> 
> Here is a simple test case.  You can see that interrupt() alone will  
> not stop the evaluation.  But changing that call to stop() will work.
> 
> import bsh.*;
> 
> public class TestStop implements Runnable
> {
>      public void run() {
>          Interpreter i = new Interpreter();
>          try {
>              i.eval( "while( true ) { print(\"hello\"); }" );
>          } catch ( EvalError e ) { System.out.println(e ); }
>      }
> 
>      public static void main( String [] args ) throws Exception
>      {
>          Thread t = new Thread( new TestStop() );
>          t.start();
>          Thread.sleep(2000);
>          t.interrupt();
>          System.out.println("main done");
>      }
> }
> 
> 
> Pat
> 
> 

I see.  So it seems like if we adhere to interrupts in the Bean Shell code,
we're still at the mercy of Java objects being invoked from the script.  Still
a hell of a lot better than doing nothing, but we're still vulnarable to
inifinite client loops or what have you.  One good news is if people use
channels for IO, in particular interruptable channels, the client is safe as
far as IO blocks responding to the script abort.  The other good news is
presumably compiled Java objects pass the muster more as far as not erroneously
blocking than some arbitrary script, so being able to stop scripted code is
probably gonna solve 75% of the cases.  But all in all, it does seem like Sun
made a hard decision regarding stopping threads.  And I can understand where it
came from.

=====
Alexey
Briggs & Stratton
1988 Kawasaki EX500 (CCS)
http://bsheet.sourceforge.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click