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

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

[Newbie] How to wait for asyncronous input

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

Contents

  [Newbie] How to wait for asyncronous input pozz <pozzugno@gmail.com> - 2012-08-10 23:25 +0200
    Re: [Newbie] How to wait for asyncronous input Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-10 19:12 -0400
      Re: [Newbie] How to wait for asyncronous input pozz <pozzugno@gmail.com> - 2012-08-11 09:07 +0200
        Re: [Newbie] How to wait for asyncronous input Hans Mulder <hansmu@xs4all.nl> - 2012-08-11 11:24 +0200
          Re: [Newbie] How to wait for asyncronous input Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-11 09:56 +0000
        Re: [Newbie] How to wait for asyncronous input Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-11 14:21 -0400

#26902 — [Newbie] How to wait for asyncronous input

I'm new to Python and I'm trying to code something to learn the language 
details.  I'm in trouble with asyncronous events, like asyncronous 
inputs (from serial port, from socket and so on).

Let's consider a simple monitor of the traffic on a serial port.  I'm 
using pyserial and I looked at the miniterm example:
http://pyserial.svn.sourceforge.net/viewvc/*checkout*/pyserial/trunk/pyserial/serial/tools/miniterm.py

The strategy is to create a thread that continuously call read() method 
while a couple of flags (alive and _reader_alive) are set:

     def reader(self):
         try:
             while self.alive and self._reader_alive:
                 data = character(self.serial.read(1))

Is it an optimized strategy to wait for asyncronous input from serial 
port?  I think in this way we have a thread that is always running and 
that always asks for new bytes from serial port.

In C I should have used the select() on the serial port file descriptor. 
  I think the select() put the thread in a sleep state and wake it up 
when some bytes are received on the file descriptor specified.

It seems the "low-level" approach of select() is more optimized then the 
"high-level" approach of miniterm.

[toc] | [next] | [standalone]

#26905

On Fri, 10 Aug 2012 23:25:51 +0200, pozz <pozzugno@gmail.com> declaimed
the following in gmane.comp.python.general:

> I'm new to Python and I'm trying to code something to learn the language 
> details.  I'm in trouble with asyncronous events, like asyncronous 
> inputs (from serial port, from socket and so on).
> 
> Let's consider a simple monitor of the traffic on a serial port.  I'm 
> using pyserial and I looked at the miniterm example:
> http://pyserial.svn.sourceforge.net/viewvc/*checkout*/pyserial/trunk/pyserial/serial/tools/miniterm.py
> 
> The strategy is to create a thread that continuously call read() method 
> while a couple of flags (alive and _reader_alive) are set:
> 
>      def reader(self):
>          try:
>              while self.alive and self._reader_alive:
>                  data = character(self.serial.read(1))
> 
	I sure hope that "data" gets returned to the main thread under some
condition <G>

> Is it an optimized strategy to wait for asyncronous input from serial 
> port?  I think in this way we have a thread that is always running and 
> that always asks for new bytes from serial port.
> 
> In C I should have used the select() on the serial port file descriptor. 
>   I think the select() put the thread in a sleep state and wake it up 
> when some bytes are received on the file descriptor specified.
>

	What you apparently missed is that serial.read() BLOCKs until data
is available (unless the port was opened with a read timeout set).

http://pyserial.sourceforge.net/pyserial_api.html
api> read(size=1)¶
api>     Parameters:	* size – Number of bytes to read.
api> 
api>     Returns:	Bytes read from the port.
api> 
api>     Read size bytes from the serial port. If a timeout is set it
may return less characters as requested. With no timeout it will block
until the requested number of bytes is read.

	serial.read() may, there for, be using select() behind the scenes.

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

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

#26911

Il 11/08/2012 01:12, Dennis Lee Bieber ha scritto:
> 	What you apparently missed is that serial.read() BLOCKs until data
> is available (unless the port was opened with a read timeout set).
> [...]
>
> 	serial.read() may, there for, be using select() behind the scenes.

Hmm..., so I could open the serial port with timeout=0 so the read(), 
that runs in a different thread, would block forever, so putting the 
thread in a sleep state until some bytes arrive.

When the main thread wants to close the serial port, the receiving 
thread can be killed (I don't know why, but I think it will be possible).

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

#26916

On 11/08/12 09:07:51, pozz wrote:
> Il 11/08/2012 01:12, Dennis Lee Bieber ha scritto:
>>     What you apparently missed is that serial.read() BLOCKs until data
>> is available (unless the port was opened with a read timeout set).
>> [...]
>>
>>     serial.read() may, there for, be using select() behind the scenes.
> 
> Hmm..., so I could open the serial port with timeout=0 so the read(),
> that runs in a different thread, would block forever, so putting the
> thread in a sleep state until some bytes arrive.
> 
> When the main thread wants to close the serial port, the receiving
> thread can be killed


How would you do that?

IFAIK, there is no way in Python to kill a thread.


The usual work-around is to have a global flag that you'd set
to True when the main thread wants to close the port.  The read
would have a timeout of 1 second of so, so that the reading
thread is woken up every second, so it can check that flag and
wind up when the flag is set.


Hope this helps,

-- HansM

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

#26918

On Sat, 11 Aug 2012 11:24:48 +0200, Hans Mulder wrote:

> On 11/08/12 09:07:51, pozz wrote:

>> When the main thread wants to close the serial port, the receiving
>> thread can be killed
> 
> 
> How would you do that?
> 
> IFAIK, there is no way in Python to kill a thread.

Correct.

> The usual work-around is to have a global flag that you'd set to True
> when the main thread wants to close the port.  The read would have a
> timeout of 1 second of so, so that the reading thread is woken up every
> second, so it can check that flag and wind up when the flag is set.

It doesn't need to be a global flag. You can make the flag an attribute 
of the thread, and then have the thread check self.flag.


-- 
Steven

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

#26922

On Sat, 11 Aug 2012 09:07:51 +0200, pozz <pozzugno@gmail.com> declaimed
the following in gmane.comp.python.general:

> Il 11/08/2012 01:12, Dennis Lee Bieber ha scritto:
> > 	What you apparently missed is that serial.read() BLOCKs until data
> > is available (unless the port was opened with a read timeout set).
> > [...]
> >
> > 	serial.read() may, there for, be using select() behind the scenes.
> 
> Hmm..., so I could open the serial port with timeout=0 so the read(), 
> that runs in a different thread, would block forever, so putting the 
> thread in a sleep state until some bytes arrive.

	No... timeout=0 says "never block" -- it will return immediately
with or without any data.

	timeout=None is "block until data arrives"

http://pyserial.sourceforge.net/pyserial_api.html#classes

> 
> When the main thread wants to close the serial port, the receiving 
> thread can be killed (I don't know why, but I think it will be possible).

	If the thread is a daemon, it should die when the main program does.
Not sure what happens on port closure -- the pending read may return
with no data, which would be a condition the thread could test for and
exit cleanly when encountered.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

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

csiph-web