Il 26/10/2016 16:18, jmp ha scritto:
On 10/26/2016 02:45 PM, pozz wrote:
Il 26/10/2016 13:16, jmp ha scritto:
[...]
I suggest you write a GUI that make synchronous calls to a remote
application, if possible. If the remote app is in python, you have
access to remote protocols already written for you, Pyro is one of them,
you can skip the low level communication part.
I'm not sure Pyro (or similar alternatives) helps in my case.
The real problem is that retrieving status from remote device is a slow
operation. If the GUI thread blocks waiting for the answer, the GUI
blocks and the user complains.
From Pyro documentation:
---
Normal method calls always block until the response is returned. This
can be any normal return value, None, or an error in the form of a
raised exception. The client code execution is suspended until the
method call has finished and produced its result.
---
So, even with Pyro, I need to have another thread that manages Pyro
communication (instead of serial communication)... additional problems.
Also from the Pyro doc:
You can execute a remote method call and tell Pyro: “hey, I don’t need
the results right now. Go ahead and compute them, I’ll come back later
once I need them”. The call will be processed in the background and you
can collect the results at a later time.
[...]
It is possible to define one or more callables (the “call chain”) that
should be invoked automatically by Pyro as soon as the result value
becomes available.
I already read that, it is the feature "Asynchronous ('future') remote
calls & call chains".
This approach can be taken also without pyro at all, just using pyserial
module (and I think all the communication libraries).
With pyserial, I can set a read timeout value of zero:
timeout = 0: non-blocking mode, return immediately in
any case, returning zero or more, up to the requested
number of bytes
In this way, I can implement exactly the same mechanism of pyro in
asyncronous mode. With pyserial I could avoid setting timeout=0, using
in_waiting property ("number of bytes in the input buffer").
Anyway I don't like this approach, because the main (and single) thread
should check in_waiting every X milliseconds.
If X is too high, I could wait for the answer even if it is already
ready in the input buffer.
If X is too low, the application consumes a lot of clocks to check
in_waiting.
I would prefer to have a callback automatically called when the read
operation is complete. And I think the only method is using another
(blocking) thread. The blocking function read returns *immediately* when
all the bytes are received. And I think during blocking time, the
thread isn't consuming CPU clocks.
I could try with asyncio feature of pyserial, but it is classified as
"experimental".
--
https://mail.python.org/mailman/listinfo/python-list
