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

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

Re: How to terminate the function that runs every n seconds

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How to terminate the function that runs every n seconds Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-01-14 19:35 -0500
    Re: How to terminate the function that runs every n seconds Marko Rauhamaa <marko@pacujo.net> - 2015-01-15 11:34 +0200
      Re: How to terminate the function that runs every n seconds Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-01-15 09:11 -0500
        Re: How to terminate the function that runs every n seconds Marko Rauhamaa <marko@pacujo.net> - 2015-01-15 16:15 +0200
          Re: How to terminate the function that runs every n seconds Marko Rauhamaa <marko@pacujo.net> - 2015-01-15 17:29 +0200

#83785 — Re: How to terminate the function that runs every n seconds

On Wed, 14 Jan 2015 22:56:11 +0530, Ganesh Pal <ganesh1pal@gmail.com>
declaimed the following:

>
> My assignment  was to write a subroutine that run itself every n
>minutes  and terminate before the main thread completes.
>
	Unless something is missing in that summary, no thread is needed either
-- just a function with a loop around a delay statement of some sort.


	However, on the basis that you are required to be dumping a message at
periodic intervals in parallel with something from the main thread AND that
the main thread has to tell the subthread when it should exit... Pseudo
(Python 2.x) code

def aThread(delay=600.0):		#default 10 minutes
	while keepRunning:
		print "thread triggered at %s" % time.time()
		time.sleep(delay)
	print "thread was commanded to exit"

theThread = threading.Thread(target=aThreading, kwargs={delay:30.0})
													# half minute
keepRunning = True
theThread.start()

for x in range(5):
	print "main loop at %s" % time.time()
	time.sleep(60.0)		# one minute, with loop total 5 minutes

keepRunning = False
theThread.join()

{There are a few bugs in the above just to make it interesting}

	The main thing to consider is that "killing" a thread doesn't work well
in Python. Instead the thread has to check for some signal telling it to
quit.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [next] | [standalone]

#83803

Dennis Lee Bieber <wlfraed@ix.netcom.com>:

> 	The main thing to consider is that "killing" a thread doesn't
> work well in Python. Instead the thread has to check for some signal
> telling it to quit.

Alas, a thread can't check anything because it's blocked by I/O.


Marko

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

#83826

On Thu, 15 Jan 2015 11:34:54 +0200, Marko Rauhamaa <marko@pacujo.net>
declaimed the following:

>Dennis Lee Bieber <wlfraed@ix.netcom.com>:
>
>> 	The main thing to consider is that "killing" a thread doesn't
>> work well in Python. Instead the thread has to check for some signal
>> telling it to quit.
>
>Alas, a thread can't check anything because it's blocked by I/O.
>
	My response to that then is: design the thread's I/O so that it is not
blocking... On Linux, maybe a timed select(); Windows? short sleeps around
a non-blocking check for available data... (if console I/O, msvcrt.kbhit();
otherwise may need some other library function to put a time-out on the
I/O)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#83827

Dennis Lee Bieber <wlfraed@ix.netcom.com>:

> On Thu, 15 Jan 2015 11:34:54 +0200, Marko Rauhamaa <marko@pacujo.net>
>>Alas, a thread can't check anything because it's blocked by I/O.
>
> 	My response to that then is: design the thread's I/O so that it
> is not blocking... On Linux, maybe a timed select(); Windows? short
> sleeps around a non-blocking check for available data... (if console
> I/O, msvcrt.kbhit(); otherwise may need some other library function to
> put a time-out on the I/O)

Ah, polling, the fig leaf that covers embarrassing design constraints
all over the world.


Marko

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

#83833

Marko Rauhamaa <marko@pacujo.net>:
> Dennis Lee Bieber <wlfraed@ix.netcom.com>:
>> 	My response to that then is: design the thread's I/O so that it
>> is not blocking... On Linux, maybe a timed select(); Windows? short
>> sleeps around a non-blocking check for available data... (if console
>> I/O, msvcrt.kbhit(); otherwise may need some other library function to
>> put a time-out on the I/O)
>
> Ah, polling, the fig leaf that covers embarrassing design constraints
> all over the world.

And to provide something constructive, I should add:

Polling is occasionally the right way forward (consider the Linux
kernel's NAPI, for example). However, it is usually bad because:

 * it consumes resources when there is no need: the CPU wakes up from
   the power-saving mode, the hard disk spins unnecessarily; the battery
   that should be good for several years, dies in the middle of the
   winter

 * it is not reactive enough as you must wait patiently for the polling
   interval to expire.


Since you brought up select(), a better choice is right under your nose:
multiplexing. Have your program block and be prepared for any possible
stimulus. However, once you do that, you realize you lose the naive
simplicity of threads. Thus we arrive at the conclusion: asynchronous
programming and processes are usually a better design choice than
threads.


Marko

[toc] | [prev] | [standalone]

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

csiph-web