How to use two threads (GUI and backend)

[pozz]

Il 27/10/2016 13:33, jmp ha scritto:
> On 10/27/2016 12:22 PM, pozz wrote:
>> 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.
>
> Threads do consume CPU clocks.
> An operation within a thread will not consume less CPU clocks, however,
> the scheduler will interrupt the thread and give other
> threads/operations a chance to process as well.
> Threads implement paralellism, not performances.

Yes of course, but when the backend thread calls the *blocking* function 
pyserial.read(), it *doesn't* consume CPU clocks (at least, I hope).
The low-level implementation of pyserial.read() should move the thread 
in a "suspend" or "waiting" state, so the thread scheduler shouldn't 
activate it. The suspend state is exited (automatically from OS, I 
think) when one or more bytes are ready in the input buffer.


> From what I understand of your context, you don't want you GUI to
> "freeze" when waiting for the remote application. That's a valid concern.
>
> You can use threads to fix that(or you can use already written working
> python libraries that would mask this low level programing, it's up to
> you).
>
> What you should not do is focus on gaining "CPU clocks". You just don't
> care. It's probably not an issue. If it is, drop python and implement
> your app in C.

Because I don't want to drop python, I want to learn the best tecnique 
to use to have the best performance.