Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #90363 > unrolled thread

Feature Request: Reposition Execution

Back to article view | Back to comp.lang.python

Contents

  Feature Request: Reposition Execution "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-05-11 13:46 +0200
    Re: Feature Request: Reposition Execution Dave Angel <davea@davea.name> - 2015-05-11 07:57 -0400
      Re: Feature Request: Reposition Execution Marko Rauhamaa <marko@pacujo.net> - 2015-05-11 15:02 +0300
      Re: Feature Request: Reposition Execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-11 22:35 +1000
        Re: Feature Request: Reposition Execution Dave Angel <davea@davea.name> - 2015-05-11 09:21 -0400
        Re: Feature Request: Reposition Execution Grant Edwards <invalid@invalid.invalid> - 2015-05-11 14:27 +0000
      Re: Feature Request: Reposition Execution "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-05-12 22:18 +0200
        Re: Feature Request: Reposition Execution Christian Gollwitzer <auriocus@gmx.de> - 2015-05-13 09:27 +0200
          Re: Feature Request: Reposition Execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-13 19:07 +1000
            Re: Feature Request: Reposition Execution "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-05-15 05:58 +0200
              Re: Feature Request: Reposition Execution Christian Gollwitzer <auriocus@gmx.de> - 2015-05-15 08:06 +0200

#90363 — Feature Request: Reposition Execution

Hello,

Sometimes it can be handy to "interrupt/reset/reposition" a running script.

For example something externally goes badly wrong.

The script is unaware of this.

Current solution would require to have an "Abort" boolean everywhere.

The abort boolean could then be set to True to indicate all code and all 
loops must abort.

This is far from the ideal solution.

I think a much better solution could be to "reposition" the "instruction 
pointer" so to speak.

However for x86 stack clean up would be necessary. I would assume python has 
a stack too... which would need cleaning up.

Perhaps the entire stack can simply be cleaned up.

So that the point for execution continuation is always "clean".... in a 
"clean state".

So this allows for the stack to be cleaned completely... without any 
trouble.

I also hope this feature gets implemented quickly cause I kinda need it.

Therefore I will give some example code to see how it could look like:

def MyFunction():

  while SomeCondition:
     RunMyCode

return

def OtherFunction():
  while BatmanIsAliveLOL:
     BustPenguins
  return

def DetectProblem:

  if ProblemDetected:
    Aborted = True
    Abort( AbortToPoint )
  return

SpawnThread( DetectProblem)

while MyMainLoop:


   AbortToPoint:
     if Aborted:
        Reset stuff

   MainCode, Call Routines.


Bye,
  Skybuck. 

[toc] | [next] | [standalone]

#90366

On 05/11/2015 07:46 AM, Skybuck Flying wrote:
> Hello,
>
> Sometimes it can be handy to "interrupt/reset/reposition" a running script.
>
> For example something externally goes badly wrong.
>

os.kill()

then in your process, handle the exception, and do whatever you think is 
worthwhile.




-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#90369

Dave Angel <davea@davea.name>:

> On 05/11/2015 07:46 AM, Skybuck Flying wrote:
>> Hello,
>>
>> Sometimes it can be handy to "interrupt/reset/reposition" a running script.
>> For example something externally goes badly wrong.
>
> os.kill()
>
> then in your process, handle the exception, and do whatever you think
> is worthwhile.

One thing that gives me trouble quite often is that Ctrl-C doesn't kill
a multithreaded Python program. Instead, you need to do:

   Ctrl-Z
   [1]+  Stopped
   kill %1


Marko

[toc] | [prev] | [next] | [standalone]

#90371

On Mon, 11 May 2015 09:57 pm, Dave Angel wrote:

> On 05/11/2015 07:46 AM, Skybuck Flying wrote:
>> Hello,
>>
>> Sometimes it can be handy to "interrupt/reset/reposition" a running
>> script.
>>
>> For example something externally goes badly wrong.
>>
> 
> os.kill()
> 
> then in your process, handle the exception, and do whatever you think is
> worthwhile.


Are you suggesting that the app sends itself a signal?

Is that even allowed?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90376

On 05/11/2015 08:35 AM, Steven D'Aprano wrote:
> On Mon, 11 May 2015 09:57 pm, Dave Angel wrote:
>
>> On 05/11/2015 07:46 AM, Skybuck Flying wrote:
>>> Hello,
>>>
>>> Sometimes it can be handy to "interrupt/reset/reposition" a running
>>> script.
>>>
>>> For example something externally goes badly wrong.
>>>
>>
>> os.kill()
>>
>> then in your process, handle the exception, and do whatever you think is
>> worthwhile.
>
>
> Are you suggesting that the app sends itself a signal?
>
> Is that even allowed?
>

No idea if it's allowed.  I didn't notice his sample was multithreaded, 
as i grabbed on the "externally goes badly wrong".



-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#90385

On 2015-05-11, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 11 May 2015 09:57 pm, Dave Angel wrote:
>
>> On 05/11/2015 07:46 AM, Skybuck Flying wrote:
>>> Hello,
>>>
>>> Sometimes it can be handy to "interrupt/reset/reposition" a running
>>> script.
>>>
>>> For example something externally goes badly wrong.
>>>
>> 
>> os.kill()
>> 
>> then in your process, handle the exception, and do whatever you think is
>> worthwhile.
>
>
> Are you suggesting that the app sends itself a signal?
>
> Is that even allowed?

Of course (at least on Unix/Linux/Posix systems).

And there's even a special case defined to make sending signals to
yourself easy: you just send them to PID 0.

From "man 2 kill" on Linux:

DESCRIPTION

       The kill() system call can be used to send any signal to any
       process group or process.

       [...]

       If pid equals 0, then sig is sent to every process in the
       process group of the calling process.

And just to make sure I ran a little test, and it works exactly as
advertised:

---------------------------------testit.py--------------------------------
#!/usr/bin/python
import os, sys, time, threading, signal

def thread1():
    while True:
        sys.stdout.write("Hello %s\n" % time.time())
        time.sleep(1)
threading.Thread(target=thread1).start()
time.sleep(2)
os.kill(0,signal.SIGKILL)
---------------------------------------------------------------------------

$ ./testit.py
Hello 1431354383.19
Hello 1431354384.19
Killed
$ 


-- 
Grant Edwards               grant.b.edwards        Yow! Hello.  Just walk
                                  at               along and try NOT to think
                              gmail.com            about your INTESTINES being
                                                   almost FORTY YARDS LONG!!

[toc] | [prev] | [next] | [standalone]

#90489

"Dave Angel"  wrote in message 
news:mailman.354.1431345441.12865.python-list@python.org...

On 05/11/2015 07:46 AM, Skybuck Flying wrote:
> Hello,
>
> Sometimes it can be handy to "interrupt/reset/reposition" a running 
> script.
>
> For example something externally goes badly wrong.
>

"
os.kill()

then in your process, handle the exception, and do whatever you think is
worthwhile.
"

Thanks for suggestion, but I need a solution which can work in SikuliX as 
well.

Especially inside an observer handler that would be ideal.

So far os.kill() is not supported in SikuliX as far as I can tell.

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#90536

Am 12.05.15 um 22:18 schrieb Skybuck Flying:
> Thanks for suggestion, but I need a solution which can work in SikuliX
> as well.

What the hell is that?

> Especially inside an observer handler that would be ideal.
>
> So far os.kill() is not supported in SikuliX as far as I can tell.

OK a quick look to the webpage sikulix.com suggests, that it is based on 
Java and Python runs on top of the JVM (Jython). So maybe there is a JVM 
based mechanism to do that.

A clean way to exit your script could be to raise an exception. It 
should propagate to the toplevel and halt your script. However it is not 
possible to back and resume the execution.

	Christian

[toc] | [prev] | [next] | [standalone]

#90541

On Wednesday 13 May 2015 17:27, Christian Gollwitzer wrote:

> A clean way to exit your script could be to raise an exception. It
> should propagate to the toplevel and halt your script. However it is not
> possible to back and resume the execution.

while True:
    try:
        run_script()  # May raise TryAgain
        break
    except TryAgain:
        pass


If you prefer to only retry a finite number of times:


for i in range(10):
    try:
        run_script()  # May raise TryAgain
        break
    except TryAgain:
        pass
else:
    # break skips past the for...else block
    raise GiveUpError('too many failures')





-- 
Steve

[toc] | [prev] | [next] | [standalone]

#90645

"Steven D'Aprano"  wrote in message 
news:5553145b$0$11119$c3e8da3@news.astraweb.com...

On Wednesday 13 May 2015 17:27, Christian Gollwitzer wrote:

> A clean way to exit your script could be to raise an exception. It
> should propagate to the toplevel and halt your script. However it is not
> possible to back and resume the execution.

"
while True:
    try:
        run_script()  # May raise TryAgain
        break
    except TryAgain:
        pass


If you prefer to only retry a finite number of times:


for i in range(10):
    try:
        run_script()  # May raise TryAgain
        break
    except TryAgain:
        pass
else:
    # break skips past the for...else block
    raise GiveUpError('too many failures')
"

Hi,

Thanks for the ideas, I haven't tried them yet.

I wonder if they will work in a multi-threaded fashion.

I doubt it.

The run_script runs in it's own thread.

The exception would have to be raise from another thread. (The other thread 
check for errors and needs to abort the run script).

I doubt thread B can interrupt thread A via exceptions/exception handling 
?!?

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#90650

Am 15.05.15 um 05:58 schrieb Skybuck Flying:
> Thanks for the ideas, I haven't tried them yet.
>
> I wonder if they will work in a multi-threaded fashion.
>
> I doubt it.
>
> The run_script runs in it's own thread.

It would be of enormous help if you would create a minimal script just 
like the above for your situation. What does it mean, runs in a thread? 
How do you achieve that from Jython?

> The exception would have to be raise from another thread. (The other
> thread check for errors and needs to abort the run script).

Well usually you can pass messages between the threads, wait for 
termination etc. I've got no experience with threading in Jython; 
however this site
http://www.jython.org/jythonbook/en/1.0/Concurrency.html
suggests that there is a large number of primitives available to do that.

Concerning "Resume", what do you expect: A) starting afresh from the 
beginning or B) continue the execution at the point where the exception 
was thrown? Because A) is/should be  easy, B) could be impossible

	Christian

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web