[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/...ls/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.

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/...ls/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/

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).

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

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

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/pyse...i.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/