Home Original page

How to use two threads (GUI and backend)

Demosthenes Koptsis demosthenesk at gmail.com
Thu Oct 27 06:44:29 EDT 2016 
Here is an example about threads and PyQT

https://www.youtube.com/watch?v=ivcxZSHL7jM&index=2



On 10/27/2016 01:22 PM, pozz wrote:
> 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".
>
>
More information about the Python-list mailing list